midiOX receives correct message & m4L doesnt' ?!

[julienb]

I guess it could be a strange question/post.
btw, I'm ok with my protodeck controller and just began to "connect it" to Live through m4L!

briefly, when I push a button, it sends a midi note on, and when I release it, a midi note off.
right.

I checked the midi note bytes sent by the protodeck using midiOX.
everything is fine.

when I'm using midiin => midiparse in order to check it in m4L... it seems m4L doesn't receive (or interpret) messages correctly.

example of message sent and understood
byte0: 0x90 (noteON, channel 1)
byte1: 0x07 (8th note)
byte2: 127 (when I push it, max velocity sent)

midiOX understands it very well.
m4L understands it ... very well


example of message sent and MISunderstood
byte0: 0x91 (noteON, channel 2)
byte1: 0x07 (8th note)
byte2: 127 (when I push it, max velocity sent)

midiOX understands it very well.
m4L understands it as a message on channel 1... and all the same for the other message:
pitch understood correctly, velocity too, .... NOT THE CHANNEL


any ideas ?!

[hoffman2k]

Does anything work in Live from channel 2 to 16?
Despite the tracks having a channel selector, I've never seen a track in Live being able to handle more than one midi channel and it even sucks at that (no PC, Sysex, etc..).

[julienb]

my interface patch sits in the track1.
it HAS TO handle midi data from and to channels 1-16
probably, the problem comes from this very ridiculous limitation

I just hope I won't have to split my patch in 16 patch, sat in 16 tracks, etc etc


I don't understand why, with max for live, this kind of limitation exists anymore...
this limitation is a VERY bad things for using m4L.

[hoffman2k]

my interface patch sits in the track1.
it HAS TO handle midi data from and to channels 1-16
probably, the problem comes from this very ridiculous limitation

I just hope I won't have to split my patch in 16 patch, sat in 16 tracks, etc etc


I don't understand why, with max for live, this kind of limitation exists anymore...
this limitation is a VERY bad things for using m4L.

I never understood why the limitation was there in the first place.
With Live 3 I worked around not having midi with Plogue Bidule. When midi came in Live 4, so started 5 years of workarounds for all the silly limitations.
Funnily enough we still have to work around these things but at least the tools we need for it are available in Live now. The workaround can't get much uglier than sending the MIDI over OSC from a Max Runtime app...

[Gregory Taylor]

The channel one issue for MIDI exists in Max for Live because it's a hosted environment. At the moment, if you want to receive MIDI in a Max for Live MIDI effect device on a channel other than 1, the only solution I'm aware of would be to route your MIDI through a Live MIDI track, set that track to send MIDI on a channel other than 1 and route it to another Live MIDI track, then use the new Max midiselect object to capture the data stream for any MIDI channel you'd need.

[julienb]

Gregory,
I'm doing that with all my tracks to monitor midi note on on my controller.
I created the same number of midi track, each one sending midi message to my interface (patch) track.
midiselecting things in m4L works fine.
but it isn't exactly the problem here (I may probably not explain it as well)

I have a controller, I have my interface patch, I have Live.
between controller and patch, I need to have 16 channel midi message feature!!
between patch and live, I only use API. excepted for the midi note on message monitoring I explained before.

I'd be really disappointed if I couldn't send/receive midi message from channels 1-16 in one track...!
I guess it is because I don't know how to do that, and not because of a limitation in this case...

indeed, in the track where the interface m4L patch sits, there is the option "MIDI FROM" and under that the midi channel and I can choose channel 1, 2 ....... 16 or ALL.

btw, I tested it: it doesn't work.
when I send midi message on channel N, if N is selected as a MIDI FROM track, the message is sent to the patch inside the track.......................... but the patch ALWAYS receives as if the message came from midi channel 1


shit!
it sucks!

I'll have to think about my patch VERY differently !!!!!
or ... I tweak my python script as an old school guy... and I won't but m4L
the second option would be very bad for me (not for abes... )


PLEASE ABES, HELP US with our poor midi protocol !!

[julienb]

I tested again and again.
probably, I didn't find the way cause of my poor skill.

I had doubts about the midiinfo result... I had the result :
even if in patch edition mode midi info gives ... the patch itself, your midi interface etc, in Live, it ONLY gives the patch itself (I guess it is one of the consequences of the patch hosting as Gregory wrote)

look at the red marks...
strange...


it is a big limitation.
I'm looking for a solution to avoid it (maybe other patch only for routing etc ? I don't know)

if anyone could give me way to explore, I could pay a beer via paypal... yes!

[ztutz]

The channel one issue for MIDI exists in Max for Live because it's a hosted environment. At the moment, if you want to receive MIDI in a Max for Live MIDI effect device on a channel other than 1, the only solution I'm aware of would be to route your MIDI through a Live MIDI track, set that track to send MIDI on a channel other than 1 and route it to another Live MIDI track, then use the new Max midiselect object to capture the data stream for any MIDI channel you'd need.

Wow, "hosted" is getting pretty close to "asphyxiated".

I guess it makes sense: for fairness sake and symmetry, since the audio guys get only one fixed stereo bus, the MIDI guys get one fixed channel.

My sympathies, julienb. It is really too bad that you got this far down the path without being told of this restriction by anyone. Seems like some kind of basic capabilities documentation would help to avoid this kind of nastiness.

[hoffman2k]

[quote="julienb"
I'm looking for a solution to avoid it (maybe other patch only for routing etc ? I don't know)

if anyone could give me way to explore, I could pay a beer via paypal... yes! [/quote]

2 solutions I can see. But its a bit messier on windows since you need midi-ox as a virtual MIDI Driver. Build a Max runtime application that routes midi-ox to M4L over UDP. Then build a UDP receiver into your protodeck patch.

The other solution is not possible yet. Since we don't know if the remote control script stuff in M4L can handle unfiltered MIDI just like normal scripts can.

[julienb]

Wow, "hosted" is getting pretty close to "asphyxiated".

I guess it makes sense: for fairness sake and symmetry, since the audio guys get only one fixed stereo bus, the MIDI guys get one fixed channel.

My sympathies, julienb. It is really too bad that you got this far down the path without being told of this restriction by anyone. Seems like some kind of basic capabilities documentation would help to avoid this kind of nastiness.

ztutz, I just thought m4L will have dropped this limitation ; because using a patch that can itself do whatever you want to do with MIDI, but a hosted patch that restricts all you can do with midi, really sucks!

I'm looking for a solution to avoid it (maybe other patch only for routing etc ? I don't know)

if anyone could give me way to explore, I could pay a beer via paypal... yes!

2 solutions I can see. But its a bit messier on windows since you need midi-ox as a virtual MIDI Driver. Build a Max runtime application that routes midi-ox to M4L over UDP. Then build a UDP receiver into your protodeck patch.

The other solution is not possible yet. Since we don't know if the remote control script stuff in M4L can handle unfiltered MIDI just like normal scripts can.

Bjorn, I really can consider my midi protocol between the protodeck and the interface patch differently.
I have:
- 87 pots which have to send CC values
- 82 buttons which have to send midi note on message
- 86 RGB leds which have to receive midi note message to be light or not (8 states including off)

so with 1 channel, it is be possible.
MORE unfriendly, but "the patch is not your friend" as said ... i forgot about it.

[Gregory Taylor]

I sympathize with the problem and I'm frustrated by the limitations myself. But the simple fact is that I don't believe that anyone in a position to comment has ever said anything other than the following: Max for Live is hosted. It gets all its MIDI from the Live application. Max for Live gets and sends all its audio to/from the Live application. Max has access to anything that the Live API gives them access to. Period. Any assumptions which don't take that into account are simply not based in fact.

If Ableton decides to allow multichannel audio output, I expect that Max for Live will support it shortly thereafter. If Live ever makes any kind of change in the "everything on channel 1" rule, I expect that Max for Live will support that change. If Live decides to support system exclusive communications, Max for Live will, no doubt, support that change. If/as Ableton decides to add more functionality to the Live API, Max for Live will add support for those changes. From that point of view, it's the first release of a work which was (and is) a work in progress.

My experience has been that there are many useful and interesting things to do in the meantime.

[julienb]

I sympathize with the problem and I'm frustrated by the limitations myself. But the simple fact is that I don't believe that anyone in a position to comment has ever said anything other than the following: Max for Live is hosted. It gets all its MIDI from the Live application. Max for Live gets and sends all its audio to/from the Live application. Max has access to anything that the Live API gives them access to. Period. Any assumptions which don't take that into account are simply not based in fact.

If Ableton decides to allow multichannel audio output, I expect that Max for Live will support it shortly thereafter. If Live ever makes any kind of change in the "everything on channel 1" rule, I expect that Max for Live will support that change. If Live decides to support system exclusive communications, Max for Live will, no doubt, support that change. If/as Ableton decides to add more functionality to the Live API, Max for Live will add support for those changes. From that point of view, it's the first release of a work which was (and is) a work in progress.

My experience has been that there are many useful and interesting things to do in the meantime.

Gregory, I completely agree.
I'm sure about future development, future features etc.
btw, in my (little) case, I had to remap another protocol with one channel... no prob for that as I wrote before.
I'll do it asap and it will work

[dc43]

Well, I just heard about this, and I'd also like to see this fixed. Live should respect what the user chooses in the input selection drop down.

If Live for Max doesn't have proper functionality with MIDI, then it will not be as powerful as one would expect. I understand about the limitation with audio signals, but MIDI isn't resource hungry as audio, is it?

[julienb]

Well, I just heard about this, and I'd also like to see this fixed. Live should respect what the user chooses in the input selection drop down.

If Live for Max doesn't have proper functionality with MIDI, then it will not be as powerful as one would expect. I understand about the limitation with audio signals, but MIDI isn't resource hungry as audio, is it?

it seems this precise thing made and make people react
I'm sure Abes will take our words to make it evolves in the (close?) future...

[julienb]

there are many workaround, I tested one with Ralf Suckow from Ableton (big thanks to him!)
I'll publish it in another thread asap (tomorrow!)

It works fine for sending & receiving MIDI data between a midi device (virtual or physical interface) & a max for live patch