mortrouge

I'm writing a piece in MAX/MSP for a trumpeter who has gotten his hand on a Morrison Digital Trumpet (

My patch is complete, except I wrote it all and tested it with my MIDI-keyboard. Testing it with the trumpet, it only reports new notes on note-off while playing legato. Playing staccato, that is initiating a new velocity with the breath controller for every note, this is not a problem. So, the first note in a row is always correct, but then it will start to be "delayed" – while playing keeping a continuous stream of breath.

I've tried seeing if I can readjust the musical instrument, but well, it isn't very friendly when it comes to interfacing. Could someone here who might have used a similar device, like an Akai EWI, direct me to some knowledge about how MIDI instruments works that keep me from making this work?

There isn't any problem when using the instrument with other software, like ABleton and other DAWs.

I'm writing a piece in MAX/MSP for a trumpeter who has gotten his hand on a Morrison Digital Trumpet (http://www.morrisondigitaltrumpet.com/).

problem-with-a-special-midi-instrument

I'm having the same problem working with an Akai EWI USB - with a continuous stream of breath, after the first note, the note being reported is the previous one, not the current one.

I wonder if this has something to do with the fact that only the first note in a stream reports any velocity value above 0 - after that first note, each note puts out a velocity value of 0 when the note is played. Breath pressure (volume) is instead reported by aftertouch, also by control change. So it's as though each note is reporting a note-off without ever having reported a note-on. Or maybe it's as though the second note in a stream provides the note-off event for the first note - just speculating, I have no real idea what's going on.

I'm having the same problem working with an Akai EWI USB - with a continuous stream of breath, after the first note, the note being reported is the previous one, not the current one. 

I wonder if this has something to do with the fact that only the first note in a stream reports any velocity value above 0 - after that first note, each note puts out a velocity value of 0 when the note is played. Breath pressure (volume) is instead reported by aftertouch, also by control change. So it's as though each note is reporting a note-off without ever having reported a note-on. Or maybe it's as though the second note in a stream provides the note-off event for the first note - just speculating, I have no real idea what's going on.


Don't have much experience with breath based instrument controllers so this all comes with some guesswork, but from your respective descriptions it sounds like Breath control mode (or legato mode) is what is expected of the sound engine and the process would go something like as follows: A note on is expected to trigger a new event (as usual) while Note offs (velocity 0) are all accepted in terms of setting pitch but the velocity 0 /note off is ignored and BC or expression or Aftertouch (or whatever MIDI message) is actually used to control amplitude/sustain of the sound at least until its value returns to zero (where it may be the case that a note off of the last midi note is or should actually be transmitted). Also the sound engine would not actually respond to any velocity messages (in terms of amplitude/brightness) and typically have a sustain phase in its envelope that enabled the new pitch and amplitude variations to be expressed without triggering a new 'note on event' for each note message received (as in what would typically happen with a midi keyboard). Hope that makes some kind of sense. In any case, I would recommend a little research into the typical midi messaging of wind controllers and response of synth patches to suit them...

OK, I think I've figured out the problem - at least for the EWI USB.

During a continuous stream of notes, the MIDI note-off for the previous note is transmitted immediately AFTER the note-on for the current note - thus pre-empting the note-on so that there's no indication of the current note until it transmits its own note-off, stepping on the next note in the series.

So printing it out in the Max window looks something like this

So now I just need to figure out a way to swap the order of the messages so that the note-off (for the previous note) takes effect BEFORE the note-on (for the current note).

69 24 (beginning of stream - note #1 on)
71 24 (note #2 on)
69 0  (note #1 off)
72 16 (note #3 on)
71 0  (note #2 off)
65 27 (note #4 on)
72 0  (note #3 off)
65 0  (end of stream - note #4 off)

So now I just need to figure out a way to swap the order of the messages so that the note-off (for the previous note) takes effect BEFORE the note-on (for the current note).


So here's a quick and dirty solution - I'm sure there are much better ways to do it, but anyway.

The note sequence from the EWI you describe makes far more sense. i.e. sending the next note on before the previous note off means that with a (monophonic) sound engine, the note will not be 'released' (in a midi sense) , at least until the player stops producing 'air' altogether. It also means that there is no special case required for dealing with the last note or breath level and some of my previous assumptions were not entirely correct…

In terms of a patch to deal with the midi I would suggest that using something like [Borax] which is pretty much designed for the task: that is to keep track of the note sequence and that the sound engine be monophonic (pretty much the default in Max anyway) and pitch is set by the next received note on as usual.

The note sequence from the EWI you describe  makes far more sense. i.e. sending the next note on before the previous note off means that with a (monophonic) sound engine, the note will not be 'released' (in a midi sense) , at least until the player stops producing 'air' altogether. It also means that there is no special case required for dealing with the last note or breath level and some of my previous assumptions were  not entirely correct… 

In terms of a patch to deal with the midi I would suggest that using something like [Borax] which is pretty much designed for the task: that is to keep track of the note sequence and that the sound engine be monophonic (pretty much the default in Max anyway) and pitch is set by the next received note on as usual.


yeah, with borax you can pretty much do a [stripnote] and then use [borax] voice count to do [!=0], so your logic is basically saying "are there notes depressed, yes or no".

Brilliant, Spectro. You've saved me hours of frustration. This totally works on Roland AE30 too. Thanks.

The related extremely valuable object is [ddg.mono], which was maybe not officially supported by c74 in 2014 when this thread started.

Problem with a special midi instrument