Max-Sysex-through in upcoming Live 9?
since Ableton Live does handle audio and gui better/faster than Max I’d like to change back. But there is this sysex-problem leaving me doubts. It shouldn’t be too hard to implement a straight through for Max’ sysex? Did you hear sth about it to come in Live 9? And no, I don´t want to use Live + Max Standalone and virtual ports again.
If you are on mac, and have M4L, you can try using my midi in/out, objects. They support sysex input and output.
If on windows, or don’t have M4L sorry, can’t help.
i’m on windows :(
"since Ableton Live does handle audio and gui better/faster than Max "
Please, could you elaborate a little bit ? What do you find so handy in Live apart, of course, the editing possibilities wich are rather poor compared to other DAW, though. I’m asking that because I’m in the total opposite way. I’m tired of all the limitations of Live and its global work-around named M4L. (The only thing that makes me happy is that Live and M4L let me know Max…) I’m in the process of doing all my performance tools in Max. At the moment, except the feeling of re-inventing the wheel, I see only advantages and no reason to look back…
leigh, your objects rock
well, it’s just factive cpu measuring of the same patches. especially when there’s much dsp/asio to do live handles the in/output much more effective. i had a patch with a lot of record~ and buffers objects, in standalone the cpu last was about 40-70% in optimized driver settings. in live the same patch was about 5-8%.
and the gui felt quicker, but maybe due to the better overall-speed of live.
on the possibility side max is an entirely different and greater world, no one would ever argue that.
Strange… At my stage of experimenting with Max, It’s the opposite. For example, the simple thing to Launch Live with an empty project need 20% of CPU. In Max, a simple patch with 16 buffers loaded with full songs : roughly 8% !
live on empty projects makes 3% at maximum even with an old toshiba 800mhz notebook.
whatever, 8% on simple loaded buffers is high. when you load 2 impulse devices you have 16 slots, lots of editing and realtime manipulation ablities and it all takes 1% which ensures the sequencers timing. if you program a sampler with similar complexity in max/msp, and sequence it then well… bet you’ll have lots more.
i think it does not make too mch sense to substitute a daw with max if you need classic daw features and dimensions. i really did it for over an enntire year, optimizing the code again and again. but with the size of the patch speed problems grew too much. therefore m4l is the best of both worlds.
Thanks for your reply.
Just curious. Your CPU % are given by wich app ? Max or a system app. My figures came from istatmenu (it’s for mac, I don’t know if it exist on windows)
Concerning your example of impulse, I totally agree. No need to reinvent the wheel, music first.
On my side, the idea is to start from a structure close to what I know well, a DAW, and to go where the wind blows, leaving all the features that I don’t need and building, often simple things, that you can only have in a DAW with a billion of work-arounds :)
At least, that’s what I think at the moment…
on windows you have the task manager for cpu monitoring.
being honest if max had a little better audio engine (regarding cpu load when using much msp and timing/clicking when sequencing audio really quick) and maybe some more own/internal straight scripting options no one would need a generalized standard daw anymore. everyone could easily build its own in a few weeks.
Back on the original topic: you could still "generate" SyEx in a M4L patch and get it to a Max Runtime via OSC (internal to your computer). I use this approach in this M4L device:
(and on several other patches I used to automate my hardware – synths, mixer and effects directly in Live)
leighhunt could you share your code so maybe some developer can port those object to win?
let’s go over the apple-divide :-) ( to much cool stuff is mac only in the maxmsp externals world ! )
The leighhunt externals are based on the ‘CoreMidi’ framework of mac OS X.
So straightforward conversion to windows is not possible.
yes. but i think that substitute the coremidi classes with other win midi library ( portmidi? ) classes/functions can be not so difficult! given that i’m returning back o coding after 20 years i can at least give a look…
Here is a thread with related discussions.