Please, someone confirm or deny

[maaz-eke]

Hi,
I don't have Max4Live, but I'm really interested in having it one day...

Now I stumbled across this:

( http://ander.fm/)

Well, M4L is great, but for live performance it is pretty much unusable if you want to use more than 4-5 M4L effects in your setup. An empty M4L device, be it MIDI or audio, uses about 5% of a single CPU. M4L runs inside the Live thread and consumes memory that would otherwise be available for Live. Moreover, it seems to be completely unoptimized for multiprocessor environments. All M4L devices run on the same core. This is a huge drawback, I will not touch on M4L again until they fix this in a future update. What a shame.

What is about it?

[S4racen]

Scaremongering....

Cheers
D

[pid]

"confirm or deny" is not possible, because it shows you assume that there is a black or white answer, which there is not. this also shows how you do not know max/m4l, as if you did you'd realise that it is all dependent on what you are programming with it and also, how you do it. this is one of the things the writer of the text you posted gets wrong. it is more complicated than that.

shreds of truth: maybe in november 2009 when m4l was at it's greenest, there were performance issues, but even so, the computer your quoted user was using must have been very very slow (5% idle?!?! - in november 2009 i had a completely awful falling apart very slow shitty computer and even i got better usage than that). nowadays, m4l performance is excellent. of course there is a performance 'hit' to live - you are encompassing an entire complex software environment inside another. running in the live thread is the amazing thing about m4l - you can patch realtime and compile real time. there are big problems with copying and pasting devices though- this is still slow. on their radar apparently.

"All M4L devices run on the same core" is not really true / partly true. one m4l device can only access one core (unlike the advanced multithreading options available in max standalone) but that is true of all 'tracks' in all 'daws' - if audio is processing it must reside in the same environment. lives still spreads its total workload across available resources automatically. it keeps some away from m4l so it can continue to run smoothly.

"I will not touch on M4L again until they fix this" is a bit like the kids that clamour for 64-bit but do not really have a clue what it would actually mean and the way they use their computer would probably make no difference to them. however, maybe that not fair of me - it just so happened that i have always wanted what m4l has to offer, warts and all, and the writer did not, which is fine of course. each their own.

there are many wishes for m4l, and ableton and cycling 74 will most probably deliver most of them in the future and surprise us with others. however, as it stands it is an environment for building your own completely unique processing routines that no-one else would do, not an environment for making a 2048-voice fft-granular synth that can drive a car on the side. although max6 looks pretty good for that...

also, it is just down to how it is approached / used / thought about. i do many complex and 'me-type' things in m4l, my current resources are modest at best. it is the best thing that ever happened to live. the writer of the text you quote has a few valid points, but you have to ask yourself why you might care?

then again, i'm one of the ones who never really had any stability problems with live 8x apart from around just when m4l was first released, and could never understand the huge issues of others. so you could always safely ignore me.

phew. that was long. not meant to be a rant - just bored and friendly.

[maaz-eke]

pid, TX a lot for Your quick and detailed answer!

I appreciate that as friendly and I see it as delighting 'deny'

TX

[oddstep]

yeah, semi deny. You can totally disable your computer with a single patch if you throw in enough real time signal processing; a lot is also dependent on what your computer is up to. i've got a 3gb ram i3 cpu consumer wintel laptop - i can run plenty of api stuff on it. the granulator runs fine... I've run complex fft patches on it with direct x that made me nervous. but that's what asio is for innit. i think a lot of the time people think that software is unusable when really they haven't thought through the design of the Liveset they are trying to use in front of an audience. Performance is about identifying what you can/can not do and working with it.

[maaz-eke]

What is about statement that

An empty M4L device, be it MIDI or audio, uses about 5%...CPU

Even if empty M4L device uses 1% it will grow to high ~25% when I'm imagining my-imaginable handy devices in every track.
Ok most probably I wouldn't do so, but still (some-staight)% cost for empty device - it makes me bit nervous

[oddstep]

not true for me. adding max for live to a liveset does increase the cpu overhead - but I don't observe a linear relationship between number of max devices and cpu use. its not that simple. I have not carried out the empty device benchmarking test, the results wouldn't help me realise my ideas.

[maaz-eke]

TX

[S4racen]

To reduce CPU usage avoid having thousands of live GUI objects set to stored and automated, if for example you want to store a number as part of your set then choose the stored only option, this makes a big difference....

Devices I originally built, very large and complex, would eat 25% CPU and now with the latest versions I'm lucky to push this into double figures under heavy loads....

Cheers
D

[oddstep]

top advice!

[trevox]

I created a Live set to accept midi live from an electronic drum kit which involves close to 20 max patches and performance is at between 15/20% with very acceptable latency. This is all midi stuff, but it certainly goes some way to disproving that 5% is used in an empty patch or adding more patches will increase the load in a linear fashion per patch. What I find is that once you add one Max patch (so M4L is running), your CPU usage goes up a bit which makes sense. Load after that really depends on what/how you are processing within your patches, not the number of them - which also makes sense. One thing to note - if you can do something natively in Live, it will use less CPU than a home made Max patch that does the same thing which I think is understandable. I tend to use Live until it does not do what I want - which is a lot when it comes to midi routing.

[Muzik 4 Machines]

i cannot confirm the numbers, but m4l really sucks juice(i used 16 constant power fades and it used 22% more cpu idling than without, which was unacceptable in a live situation, especially for such a do nothing fx

[3dot...]

m4l is a hog...
(for example built an 16 midi->Live parameter control using remote~
it took appr. 1%cpu per knob.. on a quad core processor..
not exactly ideal for studio or live situation ...
and the idea to have lfos on that device also went out the window)
and I'm betting the fault lies with Live and not Max...
it would seem that the whole process management in Live will have to be redone to fit max well inside...
and the 'bridges' between Live and max will have to be tightened..
right now at times it feels as if they work "against" one another..
I love the concept of having max integrated...
but so far ..I'm disappointed.. largely about the cpu performance..

the fact is that a set with fewer m4l devices performs much much better...

[trevox]

m4l is a hog...
(for example built an 16 midi->Live parameter control using remote~
it took appr. 1%cpu per knob.. on a quad core processor..
not exactly ideal for studio or live situation ...
and the idea to have lfos on that device also went out the window)
and I'm betting the fault lies with Live and not Max...
it would seem that the whole process management in Live will have to be redone to fit max well inside...
and the 'bridges' between Live and max will have to be tightened..
right now at times it feels as if they work "against" one another..
I love the concept of having max integrated...
but so far ..I'm disappointed.. largely about the cpu performance..

the fact is that a set with fewer m4l devices performs much much better...

1% per knob is ridiculous and totally contrary to my experience. As stated in previous post, I have around 20 patches in a live set template I use - one which has 32 knobs and 16 buttons representing my BCR2000 - and I am at less than 20%. As a matter of interest, are you using Windows or a Mac? Just trying to figure out why there is such a radical difference with our performance...

[pid]

@trevox, '3dot' was referring to multiple [live.remote~]'s, and yes, these can be a cpu hog. the reason? they are audio rate. which is fantastic if you need it here and there. however, often you do not - you simply 'downsample' the data going into [live.remote~] and performance increases drastically. if you are controlling Live control-rate processes then the downsampled signal rate is still more than enough resolution and does the task at hand.

so, while i agree certain parts of m4l are cpu hungry, and yes, of course i wish for this to be greatly improved in future releases, this is another one of those examples where max (m4l) shoots itself in the foot with regards casual users, giving the power to do something but a little more knowledge is required to get the most out of it.

examples of all these [live.remote~] things are in the m4l examples and tutorials.

now sure, the whole preset and recall features i will admit are a bit messy and cpu hogging, largely to do with the way live works for adding everything to the undo queue etc. that is a known issue and apparently they will address it in future releases.