When using live.remote~ with sample-accurate signal like in the help patch, it seems that the CPU-usage goes up. For instance, in a patch using 6% CPU, when I plug the example in the live.remote~ help file, Live CPU usage goes up to 22%. Is that normal?

I own a Mac Pro quad 2.93 if that could be of some help.

When using live.remote~ with sample-accurate signal like in the help patch, it seems that the CPU-usage goes up. For instance, in a patch using 6% CPU, when I plug the example in the live.remote~ help file, Live CPU usage goes up to 22%. Is that normal?
I own a Mac Pro quad 2.93 if that could be of some help.


cpu-vs-live-remote

There is a lot of plumbing required to update parameters in a Live set at audio rate and keep things cool in Live. Note that you can send a different value for each sample and the CPU will not increase over that value. Also adding multiple live.remote~s hooked up in this way does not continue to add CPU load at the same rate.

Apart from that, it is a bit of a hit.If you don't have to update things at sample rate, then don't. Unhooking the audio patch cord and sending a float is cheap.

i just found this message (and in the process realized that searching for "live.remote~" yields no results, but "live.remote" does; maybe not the best forum to confuse the tilde). had i found this post the other day, i would have replied instead of posting separately as i did here....

https://cycling74.com/forums/live-remote-cpu-discrepancies

the big question is the difference between plug-in parameter modulation and MFL device parameter modulation. if anyone can use the demonstration patch (attached to the other post) and record their own cpu numbers, that would be great and probably help track this down. i doubt my machine is the only one that sees a 75% cpu increase when you target a MFL device instead of a Live plug-in.

if Andrew or anyone similarly knowledgible can comment, it would be appreciated. if this situation seems right and/or likely to stay this way for a while, i will drop some of my development efforts that are underway.

thanks, all, particularly the busy elves.

i just found this message (and in the process realized that searching for "live.remote~" yields no results, but "live.remote" does; maybe not the best forum to confuse the tilde).  had i found this post the other day, i would have replied instead of posting separately as i did here....

the big question is the difference between plug-in parameter modulation and MFL device parameter modulation.  if anyone can use the demonstration patch (attached to the other post) and record their own cpu numbers, that would be great and probably help track this down.  i doubt my machine is the only one that sees a 75% cpu increase when you target a MFL device instead of a Live plug-in.

if Andrew or anyone similarly knowledgible can comment, it would be appreciated.  if this situation seems right and/or likely to stay this way for a while, i will drop some of my development efforts that are underway.

in my laptop macbook pro Intel Core duo 2.16 the CPU in LIve jump to 33 percent with 1 live.remote and over 50 with 2... is that normal?

Andrew Pask, what do you mean with this phrase?

"Also adding multiple live.remote~s hooked up in this way does not continue to add CPU load at the same rate"

On my laptop adding 1 gets to 25 or so and 2 gets me to 28 or so.

On the contrary, I have observed a linear increase in CPU usage as more live.remote~ objects are added.

Here is a written example to illustrate, and below is a simple example patch which demonstrates this.

1. A Max For Live device with 5000 live.remote~ objects causes x CPU load on my machine. 

2. Duplicating that device in Ableton's device view causes x * 2 CPU load on my machine. Each duplication adds another x * 2 amount of CPU load. 

If anyone asks why one would need so many live.remote~ objects (not necessarily 5000), here are a couple reasons:

1. Live.remote~ objects cannot be added dynamically as described 

2. There are many valid and creative cases where controlling a lot of Live parameters is required.

Here is a simple example which demonstrates this. This device uses the below JavaScript to create 5000 live.remote~ objects.

First, add the device to a track. Note the CPU usage in Ableton. Then, add the device again in the same track's device view. Note the CPU usage in Ableton. Rinse and repeat.

You can see how the CPU load scales linearly.

You can also edit the JavaScript to adjust the number of live.remote~ objects created by the device, and you can see that the CPU usage increases and decreases linearly with more or less live.remote~ objects.

LiveRemoteInstantiationTest.amxd

LiveRemoteInstantiationTest.js

adding multiple live.remote~s hooked up in this way does not continue to add CPU load at the same rate.

1. A Max For Live device with 5000 live.remote~ objects causes x CPU load on my machine. 
2. Duplicating that device in Ableton's device view causes x * 2 CPU load on my machine. Each duplication adds another x * 2 amount of CPU load. 

If anyone asks why one would need so many live.remote~ objects (not necessarily 5000), here are a couple reasons:

1. Live.remote~ objects cannot be added dynamically as described here. 
2. There are many valid and creative cases where controlling a lot of Live parameters is required.

Here is a simple example which demonstrates this. This device uses the below JavaScript to create 5000 live.remote~ objects. 

You can also edit the JavaScript to adjust the number of live.remote~ objects created by the device, and you can see that the CPU usage increases and decreases linearly with more or less live.remote~ objects. 

From a quick test I can confirm linear increase of CPU load with creation of live.remote~ objects. Apparently they are active regardless of usage in the patch. So next question would be how much the CPU load increases when using them, ie. mapping to parameters and processing data.

Thanks for confirming, and good question.

CPU vs live.remote~