Midi notes structure to value

So, not quite clear on what you want to do. Remember that QC is a "pull" beast: the consumer patches drive thngs, pulling values from their input ports. Meanwhile, the Midi source patch is getting updated continuously with all notes including ON, OFF, velocity, and after-touch. Anytime your downstream patch asks for a value from the all notes reciever, it gets dumped the whole state of the midi channel event space. This is why your patch needs to iterate through the whole structure to find what it's looking for.

Perhaps you are imagining a channel that only gets a serial Note On 57, Note Off 57, Note On 120, Note Off 120? The all notes receiver is more general, it can contemplate near instantaneous Note On 57, Note On 120, AfterTouch 120 (63), AfterTouch 57 (127), Note off 120, Note on 32, Note on 30... When your downstream patch gets around to pulling new values in, what exactly do you want to see:

Just Note 30.

Notes 30, 32, and 57.

Notes 30, 32, and 57 along with their velocity values.

Notes 30, 32, and 57 along with their velocity values and the last Aftertouch for Note 57?

For just Note on/off info, look at the Gate array within the structure returned. But do think about what you want to do if you MIDI source sends your patch a polyphonic tone cluster of notes 0-127 all at once!

Good point, I didn't consider these things. Thanks for your help and the explanation. It will be controlling a single slider so I just need it to be the most recently triggered note. would would happen if two notes arrive at once? Is there a way to make the highest take precedence or something? I ha a look at your structure key system that you made for Jersmi, very enlightening, but I still haven't had any luck with structure index member inside an iterator. Any chance you could show me?

If no one else picks up the gauntlet first, I would be happy to show you over the weekend. I am not at a Mac in my day job, so the following is by memory...

If you only have one mono-phonic midi source on your monitored midi channel, then you will be getting an Note Off for the previous Note On always before you get the current Note On. Therefore, the Gate array in the All Midi Notes patch will only have one member that is True. The index of that True is the Note 0-127. If that's the case (and I'm not mis-remembering), your iterator patch should be designed to just return the first index it finds that is True.

If your Midi source turns out to be polyphonic, then with the above design you will still get back a Note value for some note that is On, presumably the lowest one. But if you really, truly need to find the last one pressed in a polyphonic world then you would need to use a store for previous array values and compute the difference to see what was pressed last. A bit more challenging, especially since polyphonic could mean many more than 2 notes at once (and, on account of the pull architecture we spoke of, they all could change "instantaneously" from the perspective of your consumer patch if it pulls less frequently than the midi transport speed can deliver new midi messages!).

Blackburst:

Here's a little demo patch per our discussion. I snuck in the velocity as well as the note # for fun. I think using the iteration count to reset is probably bad form, and screws up note 127. But I've got to leave something for you to do! Let me know if it does the job.

Paul

Ahh of course the note on bool samples the iteration index! Thank you so much for the clever patch. What's the purpose of the queue and extra strct index mem at the end there? Do you mind if I share this (with an adjustment and your credit of course) on the VDMX forums, the latest versions no longer have a "note to value" plugin. Thanks again.

Sharing is what it is all about here. The queue is the start of handling polyphony. Extend the queue size to see more notes and add logic to pick the ones you want. Queue outputs a structure.

Interesting patch, harrisonpault. blackburst, did you look at the Global Input MIDI Value Follower? Based on your question, this is what I would have thought to try.

Ah, yes. The timeless advice: rtfm! Thanx, jersmi

This is somewhat of a color/light organ. It is a MIDI to specific value composition that triggers _1204 Particle warfare emitters at specific locations. Plug in a midi piano and go for it.

sheesh, that's embarrassing. I have never even noticed that patch. jeez. On the brighter side it was great going through harrisonpault's comp and learning a few things.

I am finding on Lion 10.7.3 that the composition you've posted, MIDILights1024.qtz, is provoking a JavaScript error

> Macro Patch
Cannot create connection from ["key_79" @ "MidiNotes_1"] to ["input_55" @ "JavaScript_1"]

and thus does not function as per the intended design.

The composition , pth_Find_MIDI_Note.qtz, works just fine. Shall be looking into extending that. Interesting point about note 127, I think that sort of difficulty has been mentioned before with other compositions.

Thanks for the find, Cybero. I should have mentioned that the MIDI needs to be tuned per specific device. It was designed for a Casio CB-1 which has that key configuration. Each MIDI device is unique and the Javascript can be fiddled with to get the results needed. For example it didn't work correctly on my e-audio 49 keystation.

Just did a Structure from File and then a Custom Selection to an E-Volution MK-249 and it's working gorgeous. Next - try the trusty Yamaha. Nice custom patch Mike :-)

Thanks! This was made for a collaboration about Kandinsky and Wagner.

My hope is to apply a unique color to each burst of particles, but since I'm moving the emitter to a new location all particle lines change to the same color. My original build had 88 particle emitters which was not very practical. Any ideas?