I'm in a situation where I want to convert MIDI 'CC' data into 'Note On' data* (leaving everything in the MIDI byte as is and only changing the type). It seems one cannot output more than one 'Note On' of a certain pitch without sending the corresponding 'Note Out' through an Ableton Live MIDI track.

Is this true? And if yes: Is there a workaround for that? (I don't want to pollute the MIDI stream with Note Off's...) Maybe sending MIDI directly through Max?

* in case anyone wants to know why: One usecase is to trigger/set things in MA Lighting's grandMA onPC which only supports MIDI notes (even for faders).

I'm in a situation where I want to convert MIDI 'CC' data into 'Note On' data* (leaving everything in the MIDI byte as is and only changing the type). It seems one cannot output more than one 'Note On' of a certain pitch without sending the corresponding 'Note Out' through an Ableton Live MIDI track. 

Is this true? And if yes: Is there a workaround for that? (I don't want to pollute the MIDI stream with Note Off's...) Maybe sending MIDI directly through Max? 

* in case anyone wants to know why: One usecase is to trigger/set things in MA Lighting's grandMA onPC which only supports MIDI notes (even for faders).


output-multiple-note-ons-through-a-live-midi-track

Doesn't seem to be much of a problem. If I bombard Ableton Live with only note on messages via midiout ("From Max 1"), it just uses up available voices e.g. in Operator. No note off to be found here. Good luck! PS: Are you sure this isn't a matter of premature optimization?

Live can output multiple Note-Ons of the same pitch from a MIDI track (inserting Note-Offs automatically). but Live does not *receive* multiple CCs of the same number and value. It just swallows the duplicates.

Ah... I just found something weird happening: If I take your example, HZ37, everything works until I delete and readd the 'midiout' object. 'Then the midi output only works sporadic until I close and reopen the patcher. Seems like a realtime update bug in Max. Allright, I will keep on testing.

Live swallowing duplicates shouldn't be that bad in most cases but it's definitivly worth knowing for data transfer! Eek. So, thanks for the input, the both of you!

Ok, I still don't get it. Maybe I'm doing something fundamentally wrong (quite likely).

Can someone point me in the right direction?

I connected a midi controller sending midi CC data from some knobs. In the example snippet below, the left side (generating random values for data 1) outputs note on's as expected while the right side outputs some single notes (most often with the values 1 and 64) AND note offs (128 x y). What the?! Also very suspicious: it seems as I'm overflowing some buffers doing it this way as the midi ouput gets more and more laggy after inputting lots of data. Hmm.

Shouldn't this work? The output in the Max patcher window is correct - the data actually sent hpwever is not.

Ok, I still don't get it. Maybe I'm doing something fundamentally wrong (quite likely).
Can someone point me in the right direction?

I connected a midi controller sending midi CC data from some knobs. In the example snippet below, the left side (generating random values for data 1) outputs note on's as expected while the right side outputs some single notes (most often with the values 1 and 64) AND note offs (128 x y). What the?! Also very suspicious: it seems as I'm overflowing some buffers  doing it this way as the midi ouput gets more and more laggy after inputting lots of data. Hmm.

Shouldn't this work? The output in the Max patcher window is correct - the data actually sent hpwever is not.


Your simplified example works for me as expected, looking at the output with a midi monitor. But notice that CC data with value 0 will generate notes with velocity 0 which are actually Note-OFF messages as defined by the midi standard.

I recreated a live set with only one midi channel, a freshly created max midi effect, pasted in the simplified example from above, and hooked it up to different midi controllers (in) and midi ox via a loopmidi virtual patch cable (out) for monitoring. Nothing fancy with that. However I still get the same behaviour. I even don't need the external connections, I can reproduce it using the MidiMonitor.amxd (in Live Suite). I added one before and one after my test device and I can see the same things happening. The data in is working as expected of course.

Example (it's the same for different controller values):

But (and that gives me a headache), with lots of fiddeling sometimes (rare!) it seems to work*:

(* allthough it's hard to say if the output corresponds to the input)

I recreated a live set with only one midi channel, a freshly created max midi effect, pasted in the simplified example from above, and hooked it up to different midi controllers (in) and midi ox via a loopmidi virtual patch cable (out) for monitoring. Nothing fancy with that. However I still get the same behaviour. I even don't need the external connections, I can reproduce it using the MidiMonitor.amxd (in Live Suite). I added one before and  one after my test device and I can see the same things happening. The data in is working as expected of course.

Example (it's the same for different controller values):
[CC 16, 0] outputs [NoteOn 16, 0]
[CC 16, 1] outputs [NoteOn 16, 1]
[CC 16, 2-127] outputs nothing

But (and that gives me a headache), with lots of fiddeling sometimes (rare!) it seems to work*:
[CC 21, 17] outputs [NoteOn 21, 17]

(* allthough it's hard to say if the output corresponds to the input)


I ran into the same problem, ended up just sending a note-off before every new note-on, haven't had any real problems with latency

@, JDUDEO: Thank you very much for mentioning that!

I tried your solution and it worked. Below is the updated simplified example:

Ok, but that's not satisfying and it feels like a bug in either Max or Live. Any ideas how to investigate further?

@, JDUDEO: Thank you very much for mentioning that!
I tried your solution and it worked. Below is the updated simplified example:

Ok, but that's not satisfying and it feels like a bug in either Max or Live. Any ideas how to investigate further?


I'm not sure if it's a bug, it may just be that MIDI was never designed to work that way, I'd be surprised if there was any hardware or software out there that was able to deal with changing velocities (after note-on) in any meaningful way, how would you even show that in a MIDI clip? Pretty sure they made aftertouch for this.

It's some time ago I read the MIDI specs but I'm quite sure there is nothing about it. Actually midi message is nothing else than (typically 3 byte long) data set:

The status looks like this [1TTTCCCC], each letter representing one bit. The 3 bits marked wirth T are the message type (CC, Note, etc.) and the ones marked with C are for the channel. The only thing that should differ from the data perspective are those T-bits.

0100] [00100000] [00000010] = Note On, Channel 5, Note number 32, Velocity 2

0100] [00100000] [00000010] = Control Change, Channel 5, CC number 32, Value 2

I assume there is some logic built into Ableton Live's midi output - maybe to protect synths from hanging notes. But as long the output is not reproducable between users/machines and inconsistent I'm not happy with that assumption.

It's some time ago I read the MIDI specs but I'm quite sure there is nothing about it. Actually midi message is nothing else than (typically 3 byte long) data set:
[STATUS BYTE] [DATA1] [DATA2]

[10010100] [00100000] [00000010] = Note On, Channel 5, Note number 32, Velocity 2
[10110100] [00100000] [00000010] = Control Change, Channel 5, CC number 32, Value 2

I assume there is some logic built into Ableton Live's midi output - maybe to protect synths from hanging notes. But as long the output is not reproducable between users/machines and inconsistent I'm not happy with that assumption.


I see what you're saying, that it should be possible to at least send the message and let the synth deal with it but Ableton already ignores aftertouch completely (though I think I heard they added it in a recent update?) and I could see them taking this precaution with note-on events. Ask support if you're curious

Update: I contacted Live's support. After some to and fro, that's their (final?) anwser:

Leider ist das so, wenn Live keine Note Off Nachricht bekommt, kann die gleiche Note nicht wieder geschickt werden. Ob es ein Bug oder "Feature" ist, ist in dieser Moment egal; ich denke, dass du einfach damit umgehen müsst.

(roughly translates to: If Live does not get a Note Off Message, the same note unfortunately cannot be sent again. Never mind if that's a bug or a feature; I think you have to deal with it.)

To add something constructive to that post: The problem of live scanning (and altering) the midi stream of every M4L plugin's midi out can get quite annoying. Regarding Live's feature of sending note offs for all 'hanging notes' when hitting the global transport stop button introduces even more problems. And yes that's not restricted to Live's midi out but every plugin's out. I'd therefore like to search for an alternative way to get midi out of M4L to the devices.

Leider ist das so, wenn Live keine Note Off Nachricht bekommt, kann die gleiche Note nicht wieder geschickt werden.  Ob es ein Bug oder "Feature" ist, ist in dieser Moment egal; ich denke, dass du einfach damit umgehen müsst.

Not satisfying.
To add something constructive to that post: The problem of live scanning (and altering) the midi stream of every M4L plugin's midi out  can get quite annoying. Regarding Live's feature of sending note offs for all 'hanging notes' when hitting the global transport stop button introduces even more problems. And yes that's not restricted to Live's midi out but every plugin's out. I'd therefore like to search for an alternative way to get midi out of M4L to the devices.

Output multiple 'Note on's through a Live midi track?