modnf

Title pretty much explains it. I've tried rigging the poly object and routing it so that it makes a list and zl.filters out any notes that are at less than 1 velocity, but this has too many problems and isn't worth posting here.

This is what I want it to do: any time the object gets a midi note or set of midi notes, send it to the output as a list. Order doesn't matter. The list's size has to be the same as the number of notes currently held down. Velocity is disregarded, but it's probably useful for deciding when the notes are going to be on the list.

Title pretty much explains it. I've tried rigging the poly object and routing it so that it makes a list and zl.filters out any notes that are at less than 1 velocity, but this has too many problems and isn't worth posting here. 

This is what I want it to do: any time the object gets a midi note or set of midi notes, send it to the output as a list. Order doesn't matter. The list's size has to be the same as the number of notes currently held down. Velocity is disregarded, but it's probably useful for deciding when the notes are going to be on the list.


how-do-i-get-a-list-of-currently-held-midi-notes

The [borax] object may be useful for this.

I don't think Borax will do the job here, it can't easily give you a list of held notes and it cant deal with different midi channels.

Here are two examples one for collecting held note numbers and one for collecting held note number and midi channel which is really useful if you are using a controller which outputs multiple channels simultaneously. Don't think I've ever used the bag object before or since this.

I don't think Borax will do the job here, it can't easily give you a list of held notes and it cant deal with different midi channels. 

Here are two examples one for collecting held note numbers and one for collecting held note number and midi channel which is really useful if you are using a controller which outputs multiple channels simultaneously. Don't think I've ever used the bag object before or since this.


dang, I was just putting the finishing touches on my rig using borax as you posted that! That setup you pasted is more attractive than mine though, and it will definitely be useful when I make the inevitable jump to multiple channels. Thank you very much.

dang, I was just putting the finishing touches on my rig using borax as you posted that!  That setup you pasted is more attractive than mine though, and it will definitely be useful when I make the inevitable jump to multiple channels. Thank you very much.


No worries, the multiple midi channel one is a bit hackish but it works fine. A more elegant solution would be to use Java or Java script.

I think I forgot to add a bang to the bag object in my first example, i'm sure you've worked it out but just bang it when you need the held notes out.

I haven't looked at leafcutter's approach so this may be redundant and or inefficient:

I'm working in a patch that needs a similar trickery...

I love your implementation Chris, but unfortunately it's not working in my situation,

because i need to keep track of multiple note-ons which may have arrived for the same pitch.

In your implementation, multiple note-ons for the same pitch are not saved, resulting in a list like this:

Any idea how could i solve this, taking your patch as a starting point?

Hey!
Sorry for pumping up this thread again,
I'm working in a patch that needs a similar trickery...

I love your implementation Chris, but unfortunately it's not working in my situation,
because i need to keep track of multiple note-ons which may have arrived for the same pitch.
For example:
60 64 60 61 60 60

In your implementation, multiple note-ons for the same pitch are not saved, resulting in a list like this:
60 64 61

Hey Playmodes, this one should do your duplicate notes, but it's a different method. It could have multiple channels, too, but I haven't added that cos I don't know how you'd want them output. It currently doesn't handle note number 0 either, but that could be added as well. HTH, Bill

Thank you very much, that works like a charm!

A variation on the ideas and patches on this thread:

-note-ons of the same pitch are stored in the list, but repetitions not sent to noteout

-note-off is generated just if the number of note-offs equals the number of note-ons stored in the list

-note-ons of the same pitch are stored in the list, but repetitions not sent to noteout
-note-off is generated just if the number of note-offs equals the number of note-ons stored in the list

Alright, so first off: I'd like to state my appreciation for all of the contributions made to this thread. I'm currently using leafcutter's single channel held note collector (Though, I'd love to eventually figure out how to incorporate the multi-channel method as well).

What I'm currently trying to accomplish is storing note values into a coll, in this format:

I figured I'd use [zl.sort] to order from lowest to highest. Then interleave with a corresponding item number list using [zl.lace] and then use [zl iter 2] to store the interleaved pairs into the coll, etc.

1. I'm not sure where I'm going wrong, but it's not currently functioning as desired. 

2. I trust there's a much more efficient way of going about this, but it's currently eluding me.

An additional thought: Before arriving at this thread, I'd tried using [thresh], but then decided held notes would probably be the cleanest for this particular patch, but eventually it'd be nice to figure out how to use [thresh] in this way. 

As always, I very much appreciate any attention this post might garner.

Alright, so first off: I'd like to state my appreciation for all of the contributions made to this thread. I'm currently using leafcutter's single channel held note collector (Though, I'd love to eventually figure out how to incorporate the multi-channel method as well).

What I'm currently trying to accomplish is storing note values into a coll, in this format:
1, lowest note value; 
2, second lowest note value; 
3, third lowest lowest note value; 
- etc.

I figured I'd use [zl.sort] to order from lowest to highest. Then interleave with a corresponding item number list using [zl.lace] and then use [zl iter 2] to store the interleaved pairs into the coll, etc.

1. I'm not sure where I'm going wrong, but it's not currently functioning as desired. 
2. I trust there's a much more efficient way of going about this, but it's currently eluding me. 


An additional thought: Before arriving at this thread, I'd tried using [thresh], but then decided held notes would probably be the cleanest for this particular patch, but eventually it'd be nice to figure out how to use [thresh] in this way. 

As always, I very much appreciate any attention this post might garner.

- Aaron

Bill, this is seriously awesome. I love that it's fluid/ constantly updating the coll. Earlier, I figured a way of loading the coll after releasing the notes, while clearing on the onset of the next batch, but this is much more 'playable' (and likely more efficient). 

I suppose the first thought that comes to mind would be to find a way of using a sustain pedal to delay the clear message.

Lastly, I'm thinking I'm gonna pull load Sam T's chord-detect/ node.js tutorial into this patch to be able to "write" coll states to files with relevant names to populate a umenu to later recall or sequence. The only real question coming from a lack of familiarity with how much of a draw on resources node.js has.

Edit: I've also been trying to figure out how to get zl.len to work. Since the outlets get taken up by zl.join, using the "length" message isn't desired.

Bill, this is seriously awesome. I love that it's fluid/ constantly updating the coll. Earlier, I figured a way of loading the coll after releasing the notes, while clearing on the onset of the next batch, but this is much more 'playable' (and likely more efficient). 

I suppose the first thought that comes to mind would be to find a way of using a sustain pedal to delay the clear message.

Lastly, I'm thinking I'm gonna pull load Sam T's chord-detect/ node.js tutorial into this patch to be able to "write" coll states to files with relevant names to populate a umenu to later recall or sequence. The only real question coming from a lack of familiarity with how much of a draw on resources node.js has.

- Aaron

Edit: I've also been trying to figure out how to get zl.len to work. Since the outlets get taken up by zl.join, using the "length" message isn't desired.

Stuff like exactly when to clear [coll] depends on exactly how you want to use it, of course, so I don't think anyone can advise much till you know exactly what you want to do. (Yep, that's deliberate overuse of the word "exact".) But what's not working in [zl len]?

instead of thresh you could use accum (1 for every note on, -1 for every note off) to control a zl.group after the coll.

1. I totally hear you, Bill. I think I know what I'm gonna do on that (the behavior) front. 

Regarding [zl len], maybe I'm just misunderstanding how it's utilized, but it just doesn't seem to work in the same way sending a "length" message into a coll does. Ie. banging a length message spits out the number of rows in the coll, but sending the first outlet into a [t l l] with the first list running to [zl len] still has yet to give me that same number.

Please tell me 'exact' was a red herring. *cold sweat*

2. Roman -- oh. interesting. This is the first I'm hearing about accum. I'll certainly give that more investigation in a bit.

1. I totally hear you, Bill. I think I know what I'm gonna do on that (the behavior) front. 

Regarding [zl len], maybe I'm just misunderstanding how it's utilized, but it just doesn't seem to work in the same way sending a "length" message into a coll does.  Ie. banging a length message spits out the number of rows in the coll, but sending the first outlet into a [t l l] with the first list running to [zl len] still has yet to give me that same number.

Please tell me 'exact' was a red herring. *cold sweat*

2. Roman -- oh. interesting. This is the first I'm hearing about accum. I'll certainly give that more investigation in a bit.

You can use the old trick of encoding pitch and channel data in bigger integers (we need 7 bits for pitch and 4 for channel, so we would fit even in 16-bit ints), then send it to [bag]. If the only thing you need is a list of pressed keys, [coll] is an overkill imho (regarding volume and shape of data). 

How do I get a list of currently held midi notes?