dalinnen

in using live.remote~, i have noticed that different types of targets have greatly different effects on the cpu. with a bare minimum session without the transport running, i notice these rough numbers (as reported by live) when each type of target is being controlled:

a Max For Live device's parameter: 75-79%

these numbers are on my computer (2.8 GHz macbook pro, core 2 duo; 10.5.8; max 5.1.3; live 8.1.1) using the live plugin "Utility" and the Max Audio Effect building block "Max GainStereo" (see image).

to reproduce on your end, i've attached the patch i made for testing this. it allows you to pick a device and parameter to control (i suggest one with a continuous range), or target the volume, panning or first send level of track one's channel strip. no audio is necessary.

do these numbers seem correct, or perhaps i am missing some optimization idea? if correct, is this always going to be the case for manipulating MFL devices?

thanks for any and all responses, on list or otherwise. anything i can do, i will gladly.

in using live.remote~, i have noticed that different types of targets have greatly different effects on the cpu.  with a bare minimum session without the transport running, i notice these rough numbers (as reported by live) when each type of target is being controlled:

regular live plugin parameters: 4%
channel strip send levels: 4%
channel strip volume or panning: 15-17%
a Max For Live device's parameter: 75-79%

to reproduce on your end, i've attached the patch i made for testing this.  it allows you to pick a device and parameter to control (i suggest one with a continuous range), or target the volume, panning or first send level of track one's channel strip.  no audio is necessary.

do these numbers seem correct, or perhaps i am missing some optimization idea?  if correct, is this always going to be the case for manipulating MFL devices?

thanks for any and all responses, on list or otherwise.  anything i can do, i will gladly.

live-remote-cpu-discrepancies

I can verify this on exactly the same setup. We'll have a look at it.

i actually just presumed that this is just to do with when m4l devices are NOT utilising a "live.param~" object to receive automations (none of the max tools do), and when you DO use this the cpu hit is not as bad for those parameters. if you want lots of fun, try modulating the devices OWN parameters with this standard '.api.SelectDevice' / '.api.SelectParameter' umenu method - my cpu goes up to 1000% (yes, 3 zeros) and above then.

it would be very interesting to know what you find andrew. i am using all this stuff a lot at the moment myself.

yes, i can verify this as well. I have a patch that drives a single parameter on an m4l device. So, m4l is incapable of modulating an m4l device, with even just a single parameter on modern equipment?

Are there any updates, or is this a massive fail? Within my first hour of using m4l the very first use case I implemented is not possible?

yes, i can verify this as well.  I have a patch that drives a single parameter on an m4l device.  So, m4l is incapable of modulating an m4l device, with even just a single parameter on modern equipment?  

Are there any updates, or is this a massive fail?   Within my first hour of using m4l the very first use case I implemented is not possible?


live.remote~ cpu discrepancies