Home › Forums › General › Using Ctrlr › howto get feedback from panel:sendMidiMessageNow()
Tagged: timers
- This topic has 6 replies, 3 voices, and was last updated 6 years, 10 months ago by Mr.ToR.
-
AuthorPosts
-
May 16, 2017 at 12:57 pm #72169
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 continueMay 17, 2017 at 3:59 pm #72170The 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,May 18, 2017 at 10:25 am #72171ok, 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.
May 20, 2017 at 6:33 am #72178timers.
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.May 20, 2017 at 11:33 am #72184ok, 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 0msMay 20, 2017 at 2:06 pm #72186You 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!
May 20, 2017 at 5:56 pm #72187Hi 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.
-
AuthorPosts
- The forum ‘Using Ctrlr’ is closed to new topics and replies.