Kasper

even if the speed of the differenet new machines goes really UP, it is not something easy to notice for the everyday use ox MAX (I don't feel an upgrade between my new mac ans the previous one, even if it is supposed to be WAY faster). probably this is because Max doesn't know how to use the different cores of the processor......

1/ Does any of you use Polys (that is the only way, isn't it?) in order to assign different processors to different parts of the same patch? IS it working well, or any problems.... ?

2/ I am not using LIVE (nor M4L) but I belive that LIVE know how to use different processors on a multi-proc machine (is that true?). So if I would decide to switch to Live or rather to M4L (using live as a shell, in a way - the main thing being Max here), would also the max part of it be distribued on the different processors?

just an idea I had.... wondering if this would not be an elegant solution (currently on a 2.53 Intel core i5, 4 cores if i understand well, and obliged to use mutes etc not to have kliks and cpu spikes on a patch which does not seem so complicated to me, not asking that much...)

hi
even if the speed of the differenet new machines goes really UP, it is not something easy to notice for the everyday use ox MAX (I don't feel an upgrade between my new mac ans the previous one, even if it is supposed to be WAY faster). probably this is because Max doesn't know how to use the different cores of the processor......

cpu-usage-on-new-macs-use-max4live

2. Yes, if one decides to use several cores in it's preferences (standard).

I don't think ableton live would make it so, that max would use several cores, if it doesn't in the first place. When it comes to M4L, live often prooves to be the limitation though.

The way I understand your question, max for live wouldn't help. Personally I find that people run into a lot of issues using max for live. For me it chrashes so much more then max, and I keep my max stuff inside live to a minimum to avoid random crashes.

Please take it into your considerations, that I am not computer/max expert.

2. Yes, if one decides to use several cores in it's preferences (standard).
I don't think ableton live would make it so, that max would use several cores, if it doesn't in the first place. When it comes to M4L, live often prooves to be the limitation though.

The way I understand your question, max for live wouldn't help. Personally I find that people run into a lot of issues using max for live. For me it chrashes so much more then max, and I keep my max stuff inside live to a minimum to avoid random crashes.
Please take it into your considerations, that I am not computer/max expert.


@kasper, it is impossible to comment specifically as you tell us almost nothing useful about your patch(es) other than anecdotal stuff. however, i would say, if you are running into the issues you say you are on the machine spec you say you have then something is very very wrong with either your setup or your patching technique. i've never so much as sniffed a computer with that good a spec and i get a great deal of dsp power in msp.

re: 1/ yes, poly~ is the way to go. poly~ is the bollox.

re: 2/ NO, m4l cannot address 'cores' in this way. it runs in a single process. it is slower than max standalone. running one environment inside another is a resource hungry feat. be careful of what you believe live can do. ultimately the moment you turn up a 'send' to a 'return' for example, those two processes have to run on the same core. this is called 'a daw' - i.e., they are all like that. also, there are a few features of poly~ that are not accessible from inside maxforlive, as the dsp environment is live's and not max's. furthermore, m4l has fixed I/O and signal vector sizes, and fixed with overdrive and audio-in-interupt on. so bearing this in mind, some dsp things are not possible. ALSO remember that both max and live, and m4l, are 32-bit applications. end of story. that means that if you are utilising memory hungry processes they can only address up to 2GB of ram anyway.

about m4l - since live 8.2.2 and max 5.1.8, m4l actually feels like a proper, really good piece of software, as opposed to the dodgy alpha it was for the first 18 months. there are complex niggling issues still if you are building huge and dense devices, but day to day use is great. do not get it to 'run max in an environment capable of x, y & z' - this is silly and will not work. max standalone is still where it is at. maybe with live9 and max6 (in one or two years or so?) things will be different somehow.

two more points: 1/ for all my text above that may seem like 'complaints', m4l rocks and is a fantastic environment. i love it. it is not 'max' though. 2/ never trust anything you read on forums. ever.

re: 1/ yes, poly~ is the way to go. poly~ is the bollox.
re: 2/ NO, m4l cannot address 'cores' in this way. it runs in a single process. it is slower than max standalone. running one environment inside another is a resource hungry feat. be careful of what you believe live can do. ultimately the moment you turn up a 'send' to a 'return' for example, those two processes have to run on the same core. this is called 'a daw' - i.e., they are all like that. also, there are a few features of poly~ that are not accessible from inside maxforlive, as the dsp environment is live's and not max's. furthermore, m4l has fixed I/O and signal vector sizes, and fixed with overdrive and audio-in-interupt on. so bearing this in mind, some dsp things are not possible. ALSO remember that both max and live, and m4l, are 32-bit applications. end of story. that means that if you are utilising memory hungry processes they can only address up to 2GB of ram anyway.

two more points: 1/ for all my text above that may seem like 'complaints', m4l rocks and is a fantastic environment. i love it. it is not 'max' though. 2/ never trust anything you read on forums. ever.


@pid - don't know whet to think about my patching technique, all I can say is that I do it since quite a long time, and see quite a lot of people having much more instable patches.... maybe my def of a "quite simple" patch is not correct (actually right now it is a 55 minutes piece for a wind trio - all treated/live-electronics in real time, so , yes there are quite some processes happening.

I am forced to use mute~ etc , which surprises me...... my set up? well, yes, an extra screen (whichg adds to the cpu, airport and communication with data from 2 iPhones, an extra mac communicating by ethrenet/maxhole....

so it works, but the change from my previous mac was not what I felt when I bought my first Titanium....

of course all of it is relative - and I can only hope that some day max will be able to use all 4 (or more) cores

_some of my friends had the same questions I have so i don't think it is SO related to my set-up

anyhow seems I had the answers about M4L. Since i don't need Live, no reason to use M4L

thank you to both.
@pid - don't know whet to think about my patching technique, all I can say is that I do it since quite a long time, and see quite a lot of people having much more instable patches.... maybe my def of a "quite simple" patch is not correct (actually right now it is a 55 minutes piece for a wind trio - all treated/live-electronics in real time, so , yes there are quite some processes happening.

I am forced to use mute~ etc , which surprises me......  my set up? well, yes, an extra screen (whichg adds to the cpu, airport and communication with data from 2 iPhones, an extra mac communicating by ethrenet/maxhole....

so  it works, but the change from my previous mac was not what I felt when I bought my first Titanium.... 

CPU usage on new MACs (use Max4LIVE ?)