Add object that can route notes to different synths depending on their position (low, mid, high)

[fferri]

I was looking for objects to go from RAW notein events to the list of active notes (e.g. note-1 vel-1 note-2 vel-2 note-3 vel-3 ....

I found objects [mono], [noteinfo], [voices] (and [keyboard]) which seem to handle similar functionality, but using different formats.

Also, I found no way to go the other way round, i.e. from such list to raw noteout-like events.

Maybe I overlook some obvious object in ELSE?

The reason I look for active notes in a list, is that I need to split the active voices by their midi note, e.g route the lowest active note to a synth, the highest note to another synth, and the remaining notes to a third synth, like it can be seen here:

So yes, I came up with my pd-vanilla implementation of such objects, and unless I overlook a solution that was already possible with ELSE, feel free to modify/add mine to ELSE.

EDIT: https://github.com/fferri/pd-active-notes

[porres]

send me those objects, I wanna see what you mean... I plan to make a new update release in 7 days, with luck this might get in ;)

[fferri]

https://github.com/fferri/pd-active-notes

[porres]

no help files? :(

[porres]

I also don't really know what you need. What if you had a list output for the 2nd outlet of [noteinfo] that showed the list of active voices, would that work for you?

[porres]

yeah, these abstractions make no sense to me :)

[fferri]

[active-notes] receives MIDI notes (packed as two-elements lists e.g. <note> <velocity>), and internally tracks their status (on-velocity/off), and at the same time outputs a list <note1> <vel1> <note2> <vel2> ... of the currently active notes with their velocity.

E.g. sending 60 127 then 62 120 then 61 110 then 60 0 outputs in this order: 60 127 then 60 127 62 120 then 60 127 61 110 62 120 and as last message 61 110 62 120.

---

[active-notes-to-midi] does the opposite: receives a list of notes and velocities <note1> <vel1> <note2> <vel2> ..., and internally tracks the status of notes, and at the same time outputs any state change in the form of MIDI note messages note velocity (i.e. 2-element lists).

E.g. sending 61 110 62 120 would produce the two messages at its outlet: 61 110 and then 62 120.
If then a message 61 110 63 100 is sent, only 63 100 will be output, because note 61 is still open at velocity 110.

[porres]

I get now how [active-notes] works, do you need that as a 2nd output of [noteinfo], would that do it?

[fferri]

And [active-notes-to-midi] goes the other way round (from list of active voices to note messages).

Keep in mind that these objects have an internal state (i.e. the note-on velocity of all 128 notes), so their output depends not only on the last message, but also on all the previous messages; in other words (see last example in my previous message) a message can leave the channel with notes open... a subsequent message can close those.

In fact, sending the empty list (bang) closes all currently playing notes.

[fferri]

I get now how [active-notes] works, do you need that as a 2nd output of [noteinfo], would that do it?

I don't "need" anything :D these abstractions already have done the job of solving my MIDI problem.

But yes, probably it would make sense to do as you say.

If you understand the problem and the solution (and those do makes sense to you), then feel free to include the abstractions in your library (also feel free to come up with a better name too, I suspect "active-notes" and "active-notes-to-midi" is not very clear ;)).

My point here is that I had one music/MIDI problem, and I looked into the ELSE library, which claims to be "a big library of externals that extends the performance Pure Data (Pd) - Miller S. Puckette's realtime computer music environment", to see if there is any object that would help me; I found similar/related objects, but in the end I had to write my own solution, so perhaps the library can be improved.

[porres]

of course the library can be improved and I'm always happy to include more functionalities, but you have to be more specific in what functionality you wand and need ;)

[porres]

sometimes you have a problem that is way too specific and you may end up needing to build things one way or another.

Now, for the sake of clarity and objectiveness, I'll ask again. Would you be happy if [noteinfo] gave you the list of active pitches? Would that work for you and make life easier? would you like to request that specific functionality?

[fferri]

I don't think I could be any more specific than this :D

I renamed the objects to more meaningful names, and added proper help patches: https://github.com/fferri/pd-active-notes
See if this way is any more clear. ;)

The class of problems being solved is general enough:

• extract the lowest playing note
• extract the highest
• extract the lowest N notes
• extract all but the lowest note
• and so on....

see the [pd pitch-based-splitting] example in the help of [notein.to.list]). Similar to [else/mono] but more flexible.

EDIT: one thing to note is that both [notein.to.list] and [list.to.noteout] keep track of active voices, so sending twice the same list to [list.to.noteout] will produce no new MIDI note, and sending the empty list to [list.to.noteout] will send a noteoff to all currently playing notes. See it as an alternative representation of MIDI events, that can be converted to and from midi noteon/noteoff messages.

[porres]

I don't think I could be any more specific than this :D

I am reaching this conclusion, but could objectively say that you don't need a list output for [noteinfo]? It's a yes or no question, you can do it ;)

If you want me to add your abstractions to ELSE and that's it, let me see if I get what they do and what I can make of it. For now I really think that whatever this is, it looks like a job for the existing [noteinfo] object.

[fferri]

No. How [noteinfo] (or any another object) alone could implement that functionality? You need 2 objects.

Did you see the [pd pitch-based-splitting] example in the help of [notein.to.list]?

[porres]

No. How [noteinfo] (or any another object) alone could implement that functionality?

No idea :) cause I didn't really get this yet ;)

Did you see the [pd pitch-based-splitting] example in the help of [notein.to.list]?

I just came here to say that I've seen it and that I really like it. I wonder if I can wrap this example as a single one called [note.route] or something. This is quite a low level thing for ELSE and it seems to only be useful for this kind of task.

[porres]

this won't likely make into my next update, but I will think about what to do here and will eventually surely include this functionality in ELSE one way or another.

Thanks for the suggestion!

[porres]

[note.split] sounds nice

[fferri]

I think that [note.split] suggests the classic split based on fixed pitch, e.g. when you dedicate the lower part of your MIDI keyboard to one instrument, and the upper part to a different instrument.

Maybe [note.splitvoices], as the goal is to split the active voices into smaller groups.

[porres]

[voice.split] - hmm, by the way, maybe [else/voices] could also do this :)

[porres]

yeah, this is a job for [voices], definitely!