Home › Forums › General › Programming › Controlling data flow/time ratios with Lua?
Tagged: sysex timing lua
- This topic has 14 replies, 2 voices, and was last updated 11 years, 1 month ago by Hecticcc.
-
AuthorPosts
-
February 15, 2013 at 7:46 pm #6392
As the title says, i am wondering if this can be done?
eg if x bytes are sent over y time delay the next message for z time.
Could this be archieved with the existing hooks, maybe using global memoryblocks & timer(s)?I am wondering because the sysex interpreter of the device i am working on gets “knocked out” at some times when alot of data is sent to it.
February 15, 2013 at 8:32 pm #6394what does it mean “knocked out” ?
February 15, 2013 at 8:33 pm #6395Yeah i need to remove those docs, they’re just misleading i’ll delete that with the next release.
February 16, 2013 at 1:43 pm #6400what does it mean “knocked out” ?
It stops responding, propably the software on the device hangs when too much data is received in a short timeframe.
Other midimessages still get handled though so cc and note data is still reacted to.My guess is that the sysex interpreter is limited to a certain data rate, not the full midi-standard 31250 baud bandwidth, and limiting the data rate of the sysex messages Ctrlr spits out at certain moments would keep the device from dropping out.
I know i could use loads of cascaded timers to spread out the load, but this would be a very “clumsy” and inflexible way imo because alot of different messages are being sent.
February 16, 2013 at 2:52 pm #6401Do you mean CTRLR stops responding or your device ?
February 16, 2013 at 3:59 pm #6404The device, all is fine @ the Ctrlr end.
February 16, 2013 at 5:20 pm #6405I’ll add an option that will delay sending of MIDI messages by a specified time, this will also be available in Lua. It’s all there is just didn’t make the parameter to sendMidiMessage() visible. Since CTRLR is using this call to send all it’s midi data out:
http://www.rawmaterialsoftware.com/juce/api/classMidiOutput.html#a023c7c703b5231048767a2ab1d24193dthen it’s possible to delay those messages, but only for MIDI devices, when using as a plugin i’d have to timestamp the MIDI messages differently.
February 16, 2013 at 6:28 pm #6410Cool, thanks Atom!
March 11, 2013 at 11:11 pm #7046Did you get around to doing this Atom? I ask because using the what() command in rev 1320 i found a great number of midi-related functions that look very interesting, but i cannot seem to get them functioning…
Examples of the functions i found for MidiMessage that i suspect i can use for this:
isMidiStart
isMidiStop
isMidiContinue
setTimeStamp
addToTimeStamp
etc...March 11, 2013 at 11:26 pm #7048No i didn’t do that yet. I’ll let you know when it’s done. Theese methods are for managing the MidiMessage class they won’t do anything to CtrlrMidiMessage.
March 11, 2013 at 11:35 pm #7049Ok, thanks for clearing this up for me.
March 11, 2013 at 11:53 pm #7051I just don’t have the time now, i started a new job. I can’t code in the new job and when i get home i’m too tired or too depressed to actually do anything. I hope this will change, i need to get a light laptop i can take with me to work so i can code on it.
March 12, 2013 at 10:36 am #7069Kinda in the same boat here so i get ya.
Started a fulltime class for network admin last month, and when i get home my son is priority 1. When he goes to sleep i am usually too tired to bother getting behind the computer – especially because i have been behind one all day, rather spend some time with the misses.
Sometimes i get a day off from the class and then i make some time to work on my panel, but these moments are scarce.
Bottom line – i don’t mind the wait 😉
March 12, 2013 at 11:45 am #7073I added a issue tracker plugin (a link in the top menu), i added this feature request so it doesn’t get lost in the crowd.
March 12, 2013 at 12:53 pm #7074Cool, thanks Atom
-
AuthorPosts
- The forum ‘Programming’ is closed to new topics and replies.