Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(feature request) add support for note off msg to [notein]/[noteout] #796

Open
mariobuoninfante opened this issue Nov 28, 2019 · 16 comments
Open

Comments

@mariobuoninfante
Copy link

@mariobuoninfante mariobuoninfante commented Nov 28, 2019

Hi,

Don't think this is a bug, but I just realized that [noteout] doesn't send note off msg, and instead note on with velocity 0.
I know you can use [midiout] to achieve that, but I was wondering whether it would be possible to add the possibility to decide what to send when the object receives a velocity value of 0.

Cheers,
Mario

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 28, 2019

this just popped up in my mind,
maybe setting the velocity to a negative value could be a suitable option to allow sending note off messages?
also cause there are piece of hardware that uses note off velocity values (!=0) to affect sound parameters, ie staccato and stuff like that

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 28, 2019

what to send when the object receives a velocity value of 0.

when you send a velocity of 0 to [noteout] to denote a note-off, you don't need to send an actual note-off message, because the velocity part has obviously been lost.

For symmetry, I guess we could simply add [noteoffin] and [noteoffout] objects, but I'm not sure it's really worth it...

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 28, 2019

Don't think this is a bug, but I just realized that [noteout] doesn't send note off msg, and instead note on with velocity 0.

it's not a bug, a note on with velocity 0 is the definition of a note off message in the MIDI world

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 28, 2019

a note on with velocity 0 is the definition of a note off message in the MIDI world

No, a note-on message with velocity 0 is not the same as a note-off message. The MIDI standard only says that the former must be treated the same as the latter.

Apart from that, I think we all agree that it's not a bug in [noteout].

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 28, 2019

yap, I know sending a note on with vel 0 is not an issue :)
mine was a statement, like I know it is not a bug, but....
@Spacechild1
not sure I got what you mean with

when you send a velocity of 0 to [noteout] to denote a note-off, you don't need to send an actual note-off message, because the velocity part has obviously been lost.

What I was trying to say there is basically that it would be great to be able to send note off messages using [noteout] (since the name doesn't directly refer to either note ON or OFF).

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 28, 2019

I think you're talking about 'release velocity' then? It's not the same as 'note off'

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 28, 2019

The only way to emulate release velocity in vanilla is with [midiout] I guess.

Anyway, objects in 'cyclone' and 'else' can deal with release velocity.

See cyclone/xnoteout and else/note.out

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 28, 2019

I guess you could rename the issue to "feature: make [noteout] send release velocity".

Maybe a new inlet/outlet to [notein]/[noteout] could do the trick (as in cyclone/xnoteout) In else I put a '-rel' flag to add this extra parameter, also an option.

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 28, 2019

I think you're talking about 'release velocity' then? It's not the same as 'note off'

note-off messages are status byte 128-143, note-on messages are 144-159. A note-on message with velocity 0 is treated like a note-off message, but it is not a note-off message

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 28, 2019

having an (optional) additional inlet/outlet for [notein] / [noteout] is not a bad idea, though.

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 28, 2019

basically like @Spacechild1 was saying, you have:

note off
byte1 = 128-143 (channel 1-16)
byte2 = 0-127 (pitch)
byte3 = 0-127 (velocity)

then you have

note on
byte1 = 144-159 (channel 1-16)
byte2 = 0-127 (pitch)
byte3 = 0-127 (velocity)

my request (and I agree I should change the title to reflect that is a request) was to implement a way to send note off bytes
this because the 3rd byte (velocity) of a note off message is used by some instruments.
I like the idea of the extra inlet/outlet, @Spacechild1 why do you say optional? are you thinking about anything specific?
when I read that about the extra inlet/outlet, I thought something like sending/receiving a 0 when it's a note off, and 1 when is a note on.

@mariobuoninfante mariobuoninfante changed the title [noteout] doesn't send note off msg (feature request) add support for note off msg to [notein]/[noteout] Nov 28, 2019
@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 28, 2019

since we have dedicated objects for all other MIDI message types (note-on, cc, pitchbend, aftertouch, channel aftertouch, program change), why not simply add [noteoffin] and [noteoffout] to make it symmetric?

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 28, 2019

I'd tend to agree, it sounds ok on paper.
I'm just a bit concerned about the possible workflow there.
in case you have 1 single object that can handle both note on and note off, you could for example simply flip a bit and turn a note on in a note off and the other way around.
In case you have 2 separate objects, then it seems to me as if it gets over-complicated.
You then have to start routing notes, not rocket science I know, but...

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 28, 2019

basically like @Spacechild1 was saying, you have:

note off
byte1 = 128-143 (channel 1-16)
byte2 = 0-127 (pitch)
byte3 = 0-127 (velocity)

then you have

note on
byte1 = 144-159 (channel 1-16)
byte2 = 0-127 (pitch)
byte3 = 0-127 (velocity)

Yup, I'm aware, having worked with cyclone and my own design of an object, I see. I guess I might be confusing the terms as I always thought of 'note off velocity' as simply 'release velocity'. But anyway, I see what you want now and I think it'd be great to have that built into Pd Vanilla.

Now, as for the design. Having a better look, simply an extra in/outlet wouldn't do it. So I guess a flag could be the case, or just a new object. I went for the 'flag' option in my design.

But anyway, bulding an abstraction over [midiin]/[midiout] wouldn't be too hard to achieve this for a quick/urgent solution.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 28, 2019

when I read that about the extra inlet/outlet, I though about something like sending/receiving a 0 when it's a note off, and 1 when is a note on.

yeah, that's what it'd do, but then you'd stop from having a note on velocity 0 for a note off message, and this will break EVERY patch. So a flag seems like the only option here to keep compatibility.

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 28, 2019

yap, you're right about the compatibility, definitely.
Actually thinking about [notein] in particular, if there's is then an extra outlet, unless you explicitly deal with that it would be super easy to mess up noteons and noteoffs.
this makes me think the separate object would probably be the best way, and yes the abstraction solution (both with [midiin]/[midiout] or the new object) is always there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.