I’m playing around with sending notes to Ableton Live, via UDP.
I have a 10 touch touchscreen panel, so I can essentially have up to 10 notes playing simultaneously, triggered from the touch panel. I have 60 buttons, and want to keep sending the midi key for as long as the button is pressed. The value of the button comes from a spread of numbers, which give the pitch.
I need to queue the messages, so that the last release sends the off command for the key.
The attached shows that if a single button is down, and back up it’s sending the right messages, but if you select a higher slice in the spread, select outputs the selected pitch number in the order that it appears in the select.
anyway, as you might have guessed, this problem of mixed up slices of multiple spreads is another strong argument for object oriented patching with VL. here object oriented means that you have to do something per note (per slice) but you don’t want to care at all what the other notes are doing:
Got it, works a treat. I need to package and send as OSC via UDP, (should have mentioned that). I had a try with the OSCBundle, or OSCMessage but just don’t have enough experience in VL… (Working on that!)
Might need some help to bundle the data up so max4live can decode it.
still not entirelly sure i understand what you need exactly, but please try this: sendingosc.zip (6.7 KB)
problems in your approach were:
you always only returned one bundle with two messages, even though looping over all your inputs: by writing the output of ToBytes into the accumulator output of the loop in every iteration, in the end you’d only get the bytes written in the last iteration out
in my example there is one bundle created in the beginning, each iteration optionally adds messages and in the end ToBytes is called only once on the bundle
same problem with the Change: you’d always write the change of one iteration into the output accumulator, overwriting the previous state, leaving you in the end with only the state of the last iteration
in my example note how the changed state of the last iteration (ie, the Change accumulator input) is always taken into account in the current iteration