Why are Max MIDI capabilities useless in M4L ?
The fact that MIDI in M4L does not allow to select multiple MIDI devices is totally absurd.
It is obvious that M4L should allow to select any MIDI in/out port and device like in Max (using midiinfo, MIDI device routing, all MIDI messages, sysex, multichannel,etc).
Live should be one of the devices.
This would make life (and Live) much simpler for users.
It seems that everyone there believe that M4L users are either beginners or professional developers. In fact most are not.
The idea that M4L is used for making MIDI or audio effects is odd and reductive.
Best regards
Roland
+1
i (as many others) am very keen to learn the reason for this incredibly annoying limitation.
as LIVE is probably the most spread software for musical live-performance and (i would assume) integration of external gear,
i can not retrace why this is not supported and why we must rely on non-cross-OS-compatible hacks or UDP communication or the like
to achieve it.
any hint from the gurus?
As I understand it, Live needs complete control over all midi/audio routings to ensure perfect synchronisation and delay compensation. So any direct midi communication of M4L bypassing the Live engine would introduce some timing error. This could be the reason why it's not supported.
thanks broc! that's what i was looking for :)
but... does that actually imply, that "hacking" your way into external midi input (eg. as with leigh hunts lh midiexternals) could interfere with this synchronisation / compensation? because - then again - if it doesn't: why isn't there *some* way to do it :)
In fact, any "solution" like Leigh's externals or UDP does interfere with Live's synchronisation/compensation.
So it can be used for some data like cc/sysex but not for time-critical data like notes.
wow. i had no clue!
thanks for that broc.
But yeah, I'd very much prefer an "open" version of Live that didn't have all the bells and whistles, but - for instance - multiple inputs/outputs from MfL. It's absurd that it isn't already there, in my opinion.
But hey, it's nice to have incentive to move away from Ableton Live, so that's a plus, I guess.
I feel as if I bought a house where the door is too narrow to bring my furnitures inside.
Some people say you can open the roof, some other you can dig a hole in the ground, but I do not have the courage to do so. It will bring me too much out of my way.
Best regards
Roland
Broc, can you give examples of this sync problem? I use Java for MIDI in M4L constantly and don't see any issues, so I'd like to understand what they are.
Hi Lee, try this.
1. Create midi track 1 and insert a clip with notes exactly on the beat, route the track output to an external device.
2. Duplicate the track and insert 5 empty M4L midi effects on this track 2 (to introduce latency).
Notice that the notes from both tracks are playing in sync due to Live's delay compensation.
3. Set track 1 to 'No Output' and insert a M4L midi effect sending the output via Java for MIDI.
According to my "theory", the notes from both tracks will not play in sync anymore.
thx - will give that a go this eve...
IDK, isn't this a Live specification problem? That they've decided to limit the scope of MfL? For some silly reason I can't quite see Cycling74 as the bottleneck ;)
Yes, definitely a Live issue, just interested that it should cause sync problems with native solutions in Max... Need to try what Broc says to understand more
Not only the MIDI, but also audio has some limitations which diminish the potential of the tool (e.g. no send~ /receive~). I believe it has to do with the differences in architecture between Max and Live, but if these could be overcome it would be amazing
@Lee, this was meant for OP, really.
oh :)
Thanks a lot for your comments but we haven't had any answer, we just just managed to cloud the issue.
I do not see why the scheduling should be a problem, MIDI objects can probably be rescheduled anyway, even if they are not graphic.
In addition, it would probably be a good idea to parse and format complex and redundant MIDI messages through M4L than spamming Live itself.
Moreover, control messages coming or going out from/to UDP should be gently resample to reduce unnecessary charge (at the moment issuing lots of latencies and crashes in Live).
A whole Live schedule control would be very useful in M4L.
> A whole Live schedule control would be very useful in M4L.
Nice project, L4M (Live For Max) as counterpart of M4L.
Totally agree on a L4M project :-)
Live for Max would use the Max flexibility goin' beyond Live limitations ( too much tempo related paradigm, no multiple audio/midi in/out for devices, etc. ).
Dream for Max 9 or 10 ?? :-D
"L4M" : First thing I asked to EJ when I heard about M4L ;-)
I would now expect a full coupling framework of both M&L
well perhaps Live devices in Max7 is a start :-)