howto get feedback from panel:sendMidiMessageNow()

Home Forums General Using Ctrlr howto get feedback from panel:sendMidiMessageNow()


Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #72169
    • Topics: 7
    • Replies: 51
    • Total: 58

    Does anyone know of a trick or method to receive a feedback from panel:sendMidiMessageNow(CtrlrMidiMessage(midiMessage))
    I need to do the following:

    result = panel:sendMidiMessageNow(CtrlrMidiMessage(HexString))
    continue = false
    if result then
    continue = true
    until continue

    • Topics: 7
    • Replies: 51
    • Total: 58

    The problem is that if you issue a couple of panel:sendMidiMessageNow() calls, Ctrlr sends all of them at the same time. You can see this in the midi monitor. There should be an adjustable delay between them. This causes synth to not understand what’s coming in.

    I really hope Atom would implement a delay between midi sends feature.

    I’m on Mac.
    Version = 5.3.198, Build date = Tue Mar 15 15:53:07 PDT 2016, Branch = Nightly, Juce = 4.0.2, libusb = 1.0.19, liblo = 0.28,

    • Topics: 7
    • Replies: 51
    • Total: 58

    ok, apparently there is a property called “panelMidiGlobalDelay” which puts a delay between each midi send. This solves my problems but I have to check if it creates any other performance issues.

    human fly
    • Topics: 124
    • Replies: 1070
    • Total: 1194
    • ★★★★

    Possemo has shown me a great panel with loads of methods in it,
    for the matrix1000, seems to be Atom’s work. the matrix1000 has
    delicate sysex timing issues, as i understand it, so there are
    timers on various events to create delays while data is passing
    or writing.

    have you noticed that getRestoreState pauses MIDI?
    i’ve seen the ‘pauseMIDI’ script elsewhere as well.
    both used for letting midi pass one way only until
    transfer complete, to avoid 2way/midithru looping.

    i would VERY MUCH like to understand all about this.

    eg: what is that little script header intended to
    stop indexing issues as startup with getRestoreState,
    getProgramState – what’s that all about then? that
    seems to get included in many methods, rather than
    just a panelIsLoaded method.

    • Topics: 7
    • Replies: 51
    • Total: 58

    ok, apparent this actually would create latencies on the modulators as well.
    So if you’re sending multiple messages for a program and need to have a little delay between each message, your synth might require a small delay between each message. so the solution is to use this parameter programatically and keep it normally at 0ms to avoid latency on the modulators.

    this is how I use it.

    panel:setPropertyInt(“panelMidiGlobalDelay”,20) — Set MIDI delay to 20ms
    panel:setPropertyString(“panelMidiPauseIn”,”1″) — disable MIDI input
    for s=1, 5, 1 do panel:sendMidiMessageNow(CtrlrMidiMessage(MidiMsg[s])) MidiMsg[s] = “” end — send 5 Midi messages
    timer:setCallback (9, TimerCallback) timer:startTimer(9, 1000) — enable MIDI input
    panel:setPropertyInt(“panelMidiGlobalDelay”,0) — Set MIDI delay back to 0ms

    • Topics: 45
    • Replies: 550
    • Total: 595
    • ★★★

    You can also look at my Pro2 panel.
    Look at Timers method (timers 3 and 4) and corresponding bank receive / bank send in the BankProceed_OnChange method under Programs library methods.
    Ctrlr was indeed sending too fast for the Pro2 to load. Therefore I introduced a 150ms timer.

    timer:setCallback (3, timerCallback)
    timer:startTimer(3, 150)

    This means that the code in timer 3 is executed every 150ms.
    In timer 3 you need to foresee a way to stop the timer at a certain moment.

    Good luck!

    • Topics: 7
    • Replies: 51
    • Total: 58

    Hi goodweather,

    Thnx for your post.
    Actually, initially I was using timers but I had issues when a program was loaded from the library and when multiple non-midi-sending-modulators were updating at the same time; sendMidi sometimes sent very close messages even when I used timers, so to fix that I had to even include an additional initial delay as well to wait for modulators to finish updating, and then sending multiple messages with delays in between them, that worked, but that initial delay changes from system to system depending on cpu power and also it took a lot of milliseconds 🙂 timer method made additional processing and additional code etc, so now with this method I don’t have to care about any timing, different systems or timers etc and I can send multiple messages as quick as I want, not slower, not faster.
    now with setting the global delay programmatically, it works flawlessly 🙂
    I found this method to be very clean and working very nicely.
    I highly recommend it.

    Thnx a lot.

Viewing 7 posts - 1 through 7 (of 7 total)
  • The forum ‘Using Ctrlr’ is closed to new topics and replies.
There is currently 0 users and 49 guests online
No users are currently active
Forum Statistics
Threads: 2,495, Posts: 17,374, Members: 77,605
Most users ever online was 12 on January 22, 2019 3:47 pm