note,midinote,velocity, and duration don't behave as expected with namespace objects

[charlieroberts]

These messages should behave the same as they do with devices; that is, calls to velocity and duration should alter subsequent note and midinote messages. Currently all messages are just sent directly to Max and don't generate MIDI messages.

See this Slack thread for reference.

Question for @grrrwaaa : does anything need to happen internally to the gibberwocky Max object to make namespaces generate MIDI messages? I'm guessing it does...

[charlieroberts]

A little more poking around... sending the message:

midinote mynamespacename 60 127 1000

... from the client yields the following error in Max:

pathforward • could no resolve requested object (parent::mynamespacename)

The ideal behavior would be:

1. Assuming a midinote message is received, generate the appropriate midi message.
2. Check to see if there are any params (scripting names) matching the name included in the message.
   a. If yes, forward the midi message to the appropriate destination.
   b. If no, send the midi message out the leftmost outlet of [gibberwocky].
3. The behavior above would only occur if the message from the client starts with midinote.

Seem reasonable @grrrwaaa ?

[grrrwaaa]

Hey all

I think the assumption was that namespace() is there to handle any generic kind of messaging, rather than assuming a specific format or protocol, and that's why it doesn't handle midinote/velocity/etc. in any special way. But I can see that is confusing, and I could add support for it if preferred. Still, it's unclear what the output should be -- given a message "bob midinote 42 64" should the 'bob' receiver receive "midievent 42 64"? This would be the nearest equivalent to the automatic conversion that happens for devices.

However if so, we'd also need to modify the editor to convert "note" messages. Right now, "note" messages to a device are converted to "midinote" messages before being sent over the websocket, but this conversion doesn't happen for messages to a namespace.

Graham

[charlieroberts]

OK, so I'm revising my proposal because some of what I said before didn't make sense:

Any message starting with midinote (or add <time> midinote) gets special treatment, where the rest of the message is used to generate a midi event. This event is then forwarded to the argument following midinote, which might identify a device, a param, or a namespace. They're all treated the same way.

Assuming this sounds good, I will modify the editor so that all params and namespaces have support for note, midinote, velocity, and duration.

[grrrwaaa]

I'm not sure how that works for params. Right now the websocket protocol is that messages to params always begin "set <paramvalues...>" -- and usually the target is a UI object in Max. Would you mean that the <paramvalues...> would begin with "midinote", and be converted to "midievent 144" in that case? I'm not sure that this would ever be used.

I'm still not entirely convinced it makes sense to do this for namespaces -- I think midinote handling could fairly be considered user-level? That is, for a namespace end-point, a user might not want the message automatically to be converted to midievent codes.