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.
Queue Problem.v4p (20.3 KB)
is it possible to trigger note on of the same note multiple times? so can one finger press C and another finger as well? do you send the notes with the vvvv UDP nodes?
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:
Queue No Problem.zip (6.7 KB)
Thanks Tonfilm, much appreciated, although I can’t open this in 35.8, will this need to be opened with the Alpha?
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.
on the max side I am just triggering notes when the velocity changes.
Osc bundle in vl over UDP is a case for @joreg
Any more thoughts on bundle in vl over UDP?
basically like this…to get multiple inputs on the OSCBundle node select it and press Ctrl+. (requires latest alpha or b>35.8)
SendingOSC.vl (9.3 KB)
but note that this will send both messages all the time, which may not be desired. to optimize this, the vl osc library needs to still be tuned a bit.
great, and the output of the ToBytes node would fit into the AddRange node in the patch i posted above.
then it seems you’re not using b>35.8 as i suggested above!?
Right, on the correct version, but still not an expert on vl and getting a bit confused…
Que a little problem.zip (14.0 KB)
but you forgot to mention what your problem is. also please remove stuff from that patch that doesn’t show your problem to make it easier for us to understand what you’re struggling with.
I am trying to get my multitouch surface to act like a piano, in that when you hold the virtual buttons down, the keys remain on.
When simultanious presses create multiple velocity ons, and a pitch, when each button is released, it needs to send a corresponding velocity off, with the same pitch.
Press a button and it sends 60,60, and release and it sends 0,60
I’ve tried to combine the two vl patches above, but I am getting stuck on how to trigger a send command when the toggle changes between on and off.
Que a little problem 2.zip (6.1 KB)
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
That’s working brilliantly now!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.