add support for "note off" messages

[porres]

[notein]/[noteoff] only deals "note on" messages, which is ok for most cases, but MIDI also has a special "note off" message and this is the only one not supported by Pd (unless you use [midiin]/[midiout]). I'm then proposing adding support for it with a flag in note in/out objects ('-rel' for release maybe).

The note off message with a note off velocity has been relatively rare for the most part but some new controllers have been supporting it back (there's been some discussion on the pd list about it) and I don't see a good reason not to better support it in Pd. It can play a nice part in designing synths, like being able to set a particular envelope release setting for the note.

It seems that controllers with MPE support are rather likely to also include this. I take this from a MIDI file example that MAX uses in its documentation of MPE objects and also this external that supports note off https://github.com/DanielRudrich/pd_mpe while ignoring many other possible MIDI messages.

Hence, having support for note off can also improve Pd's handling of MPE, allowing users to create abstractions for it without the need of externals like [mpe] referenced above and it could even be an alternate solution for the #2117 issue

[porres]

[notein] actually reports "note off" messages, but the velocity is given as '0' regardless of the actual release velocity. This needs to be documented and I'm gonna do it but it narrows down how we could actually implement this.

I'm now thinking of a '-off' flag that gives us an extra outlet/inlet. For [notein] it'd have at least 3 inlets if a channel is set, or 4 if not.

The extra in/outlet is for release velocity. In case of [notein], a Note Off message with a release velocity of, say, 111, gives us the same value of '0' for the 2nd outlet and comes out as such in the 3rd outlet. A 'note on' message gives us '0' release velocity.

My 1st idea would be to make the object only output release velocity with such a flag, so no new number of in/outlets, so the object without a flag wouldn't respond at all for note off messages and it would be easy to manage things with 2 instances of the object. This is not a pretty idea as someone would obviously always need 2 instances of this object, one just for note on and another for note off, and now it doesnt make much sense because the object without a flag also does output data for note offs anyway. Hence, as I say, this seems to narrow down to the other above solution that I gave.

[Spacechild1]

I'm now thinking of a '-off' flag that gives us an extra outlet/inlet. For [notein] it'd have at least 3 inlets if a channel is set, or 4 if not.

I think this is rather confusing. If you are interested in note-off velocities, I guess you want to get note-on and note-off events as separate messages anyway. With your proposal that would be rather cumbersome.

My 1st idea would be to make the object only output release velocity with such a flag, so no new number of in/outlets,

That's what I would have suggested!

so the object without a flag wouldn't respond at all for note off messages and it would be easy to manage things with 2 instances of the object.

Why would [notein] - without flags - not respond to note-off messages? Obviously, that would be a breaking change.

You can simply filter out note-offs with [stripnote].

However, for consistency, it might be nice to also offer a -on flag where [notein] would only output note-on messages. Then you can just use a pair of [notein -on] and [notein -off] - dead simple!

[porres]

However, for consistency, it might be nice to also offer a -on flag where [notein] would only output note-on messages. Then you can just use a pair of [notein -on] and [notein -off] - dead simple!

I had thought about and at first it seemed weird, on second thought, yeah, that doesn't look that bad.

[porres]

I think this is rather confusing. If you are interested in note-off velocities, I guess you want to get note-on and note-off events as separate messages anyway. With your proposal that would be rather cumbersome.

Actually, I've been using something like this in an external and it makes things work nicely. The so called note on velocity with a note on intensity value is usually used to set the gate on value of an envelope and we need the '0' that a note on message gives as a gate off message to start the release section of the envelope.

If we have this as a list with 3 elements and the 2nd one is always this gate on/off switch, things get easy. The third element is then unpacked and used for something else, usually to set the release parameter of the envelope.

It goes something like this inside a [clone]

[mariobuoninfante]

what about having an extra oulet (in between vel and channel or rightmost) that tells you if it's a note on or off (0/1).
this might be a bit more consistent since it wouldn't change the behaviour of the velocity outlet.
we would always be returning something correct - i.e. note off actual velocity instead of a Pd interpretation of it.
and the 0/1 coming out of the new outlet can be used for any particular logic.
then maybe a new flag could be something like -old (or any other appropriate one) to retain the current behavior and return vel 0 for any note off value.
just a thought

[mariobuoninfante]

since it wouldn't change the behaviour of the velocity outlet.
it would actually change the current behaviour but, would make it more consistent... for lack of a better word.

[sebshader]

since it wouldn't change the behaviour of the velocity outlet. it would actually change the current behaviour but, would make it more consistent... for lack of a better word.

the interfaces of pd's objects don't break backwards compatibility

[porres]

what about having an extra oulet (in between vel and channel or rightmost) that tells you if it's a note on or off (0/1).

an extra output to say if it's a note on (1) or off (0) velocity is how [xnotein] from cyclone works. I don't like this idea. I was defending my seemlingly "cumbersome" option, which has a use case, but I don't really need it to be like that and I can argue that Pd does not have [adsr~] from ELSE which would work nicely with it. So I guess a "-on" and "-off" flag makes things at least easier to understand.

For [noteout] we'd only need an 'off' flag. Suggesting people to use [stripnote] instead of having an '-on' flag is also a good idea and makes things easier and more consistent... just an '-off' flag for both [notein] and [noteout]. I'm leaning into this solution and could make a PR for it.

[mariobuoninfante]

since it wouldn't change the behaviour of the velocity outlet. it would actually change the current behaviour but, would make it more consistent... for lack of a better word.

the interfaces of pd's objects don't break backwards compatibility

this is a good point for sure. my thinking there was that the current behaviour is not correct. Pd hides information, or changes it if you want.
that said, I understand what you mean and that this could have an impact of some sort.

but I don't really need it to be like that and I can argue that Pd does not have [adsr~] from ELSE which would work nicely with it

well, I'm pretty sure that people still make ADSRs in Pd even without externals. Also, it might be used in other ways that we are not considering here.
Hence why I said "the 0/1 coming out of the new outlet can be used for any particular logic."

[porres]

this is a good point for sure. my thinking there was that the current behaviour is not correct.

it is actually quite meaningful and simple, makes total sense to me.

"the 0/1 coming out of the new outlet can be used for any particular logic.

you'd have to show in a patch how easy it is to deal with it and where and how it provides an improved user experience than other cases, like the one I posted in the comment above.

I'm pretty sure that people still make ADSRs in Pd even without externals

sure, and it's not quite easy, and I guess that living only with vanilla is for ninjas only and that's my point, so an easy and meaningful solution such as the idea of just having a version that outputs note off is well sufficient for pd vanilla ninjas that need this. I'm building a system in ELSE where it's pretty easy to manage all this with [voices] instead of [poly] to communicate with [clone], so it all makes sense, but it doesn't work like that out of the box for vanilla anyway... so in the end I can't really show how this solution I posted is really easy to use and integrated into some structure already provided by vanilla, and this is beyond the usage of else's [adsr~].

[porres]

to sum up my point, life is usually hard in vanilla, you have to work for it all the time, so having a [notein -off] is a reasonable strategy and there is no need to try to make things more complex so they get more 'convenient'.

The important thing here is to provide better native support for this kind of message, the main issue is that I really think it's bad that you cannot easily retrieve this MIDI message in Vanilla. We can get lost in the bikeshedding of how to better provide this, but it's just important that it gets done, and unless you have a real case and you can show in a patch how much better some particular idea is, we're just wasting time and energy.

[porres]

Ok, Pull Request is there, tell me what you think of it. Works nice on my tests

[mariobuoninfante]

I don't want to kick up a fuss about this but at the same time I think it deserves an answer, because I get a really weird vibe when reading certain things (or when things are written in a certain way, if you prefer) and personally I think that's not a constructive way to discuss things, not here, not anywhere.

this is a good point for sure. my thinking there was that the current behaviour is not correct.

it is actually quite meaningful and simple, makes total sense to me.

If the current behaviour is that you always get velocity 0 with noteoff regardless the actual velocity value, well that's wrong. it's just a fact (incoming data is ignored and turned into 0). then, if we prefer this behaviour or just want to keep it for consistency, that's a totally different story.

you'd have to show in a patch how easy it is to deal with it and where and how it provides an improved user experience than other cases, like the one I posted in the comment above.

here's put it in the same context as yours.
it is not easier but, it's easy nonetheless. what you gain from this approach (4th inlet telling you if it's noteon or noteoff) is simply that you can now get the real velocity value from the 2nd outlet, not a Pd interpretation of it. It's part of the MIDI protocol and just because is a niche thing that doesn't mean Pd should tweak it.
then again, we lived with that for years and there are workarounds, I perfectly know that.

sure, and it's not quite easy, and I guess that living only with vanilla is for ninjas only and that's my point, so an easy and meaningful solution such as the idea of just having a version that outputs note off is well sufficient for pd vanilla ninjas that need this.

I don't want to get bogged down in this but, I just want to say that there's a lot of assumptions here (the ninja bit).

I'm building a system in ELSE where it's pretty easy to manage all this with [voices] instead of [poly] to communicate with [clone], so it all makes sense, but it doesn't work like that out of the box for vanilla anyway... so in the end I can't really show how this solution I posted is really easy to use and integrated into some structure already provided by vanilla, and this is beyond the usage of else's [adsr~].

I'm not sure how this is relevant.

We can get lost in the bikeshedding of how to better provide this, but it's just important that it gets done, and unless you have a real case and you can show in a patch how much better some particular idea is, we're just wasting time and energy.

I personally think this is a really bad way to interact with anybody, anywhere. especially on a github page of an open source project. It wouldn't make anybody feel welcome, it certainly doesn't make me feel like that. And I'm sorry to say this is not the first time that I experience this kind of interaction.

For the records, the more I think about this

However, for consistency, it might be nice to also offer a -on flag where [notein] would only output note-on messages. Then you can just use a pair of [notein -on] and [notein -off] - dead simple!

the more I like it.
So, I'm not even trying to push my proposal but, I simply wanted to reply to what I found is a bit of a weird message.

[porres]

If the current behaviour is that you always get velocity 0 with noteoff regardless the actual velocity value, well that's wrong.

why? some syths do not support release velocity at all, which is quite rare and has been mostly lost to oblivion over the decades. In most cases, usually, a note on of 0 is considered a note off and many systems rely on it. Getting an actual note off message in theses cases would make the system responseless. It is usual to translate this into a note on message with a 0 velocity, and this was intentionally done in Pd because of that. It is not an accident, not a bug.

[porres]

it is not easier but, it's easy nonetheless.

you're not actually dealing with the release velocity in order to use it for something else, like setting the release time of adsr, and it becomes more cumbersome to do so... in my proposal I showed how it is much simpler, and you just connect the same note on velocity to control the gate, no need to add a multiplier to the on/off flag. This is why I said I didn't like this approach much, and is already given by [xnotein] from cyclone, like I said.

I'm not sure how this is relevant.

I'm trying to say that although I think my first proposal can offer a clear and easy way of handling things, it is not really possible with the structure provided by Vanilla, using [poly] and [clone], so it makes things pointless and doesn't make much sense in the end. So we can just consider the other option that doesn't look that bad in the end and is much simpler structurally, and it makes good sense.

I'm not even trying to push my proposal but, I simply wanted to reply to what I found is a bit of a weird message.

Cool, sorry for being blunt, I'm just trying to get things done quickly and I feel that sometimes we can get lost in endless discussions on github, and github issues actually seem like a place for keeping focus, making things short, cutting to the chase and all. Otherwise it feels more like a chat room or something and I would act differently.

Sorry again, cheers

[sebshader]

I think because object interfaces need to be backwards-compatible the focus should definitely be on optimal design rather than getting things done quickly, since such interfaces can never be undone.
personally so far I think the -off flag makes sense and is good design, because the info coming in is the exact same as note ons (but the note off is also a note in/note out..). and in contrast the extra-outlet design would probably involve [list prepend] with a [route 0 1] every time.
Might make sense to include an "-on" flag for convenience/consistency as well though (not having to use [stripnote])
But sometimes it makes sense to let design decisions marinate for a bit in order to contemplate them further..

[Spacechild1]

I think because object interfaces need to be backwards-compatible the focus should definitely be on optimal design rather than getting things done quickly

+1