howto get feedback from panel:sendMidiMessageNow()

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

Tagged: 

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #72169
    Mr.ToR
    Participant
    • 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
    repeat
    if result then
    doSomething()
    continue = true
    end
    until continue

    #72170
    Mr.ToR
    Participant
    • 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,

    #72171
    Mr.ToR
    Participant
    • 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.

    #72178
    human fly
    Participant
    • Topics: 124
    • Replies: 1070
    • Total: 1194
    • ★★★★

    timers.
    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.

    #72184
    Mr.ToR
    Participant
    • 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

    #72186
    goodweather
    Participant
    • 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!

    #72187
    Mr.ToR
    Participant
    • 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
Ctrlr