Andy Turner

hi, i am wondering where the fault lies in my patch. i have a cycle object driving a live.dial via live.remote, but my processor goes to 99% utilization with only the volume control going min to max and back again.

Again, it may be a problem with another aspect of the patch being sub-optimal, but wondering if anyone else is seeing a a hit on the processor with live.remote?

Alternatively, is there a way to make the data less dense, by polling the signal at an interval of say 2ms to relieve the strain? I want to drive a midi mappable knob and it's only 7-bit anyway so i only need 128 discrete values. Maybe just send a list to the knob and iterate through the list from min to max and back again?

what are you guys doing in this regard? basically i want to make an lfo for a "midi-mappable" knob in live, like to drive any arbitrary control in live with a sine wave so that the automation is written and exposed.

hi, i am wondering where the fault lies in my patch.  i have a cycle object driving a live.dial via live.remote, but my processor goes to 99% utilization with only the volume control going min to max and back again.  

Alternatively, is there a way to make the data less dense, by polling the signal at an interval of say 2ms to relieve the strain?  I want to drive a midi mappable knob and it's only 7-bit anyway so i only need 128 discrete values.  Maybe just send a list to the knob and iterate through the list from min to max and back again?

what are you guys doing in this regard?  basically i want to make an lfo for a "midi-mappable" knob in live, like to drive any arbitrary control in live with a sine wave so that the automation is written and exposed.


live-remote-processor-intensive

The cpu load of live.remote~ greatly depends on the target, as shown here

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

The cpu load of live.remote~ greatly depends on the target, as shown here 

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


You shouldn't have any problems with modulating non MFL parameters. Also, it's usually a good idea to choose carefully which parameters you need to use live.remote~ at audio rate for and which ones will be fine when modulated by a straight live.object or whatever.

Also make sure you're using the latest MaxMSP, we included some parameter filtering options in 5.1.5

-parameters: new attribute to toggle deferral of automation and remote control output to the GUI thread; off by default, this attribute can be used to reduce the frequency of value changes resulting from automation and significantly reduce processor load. In combination with the new parameter_speedlim attribute, device developers now have fairly comprehensive control over the automation of their parameters.

Check the update limit and Defer Automation output attributes in your target MFL parameter.

live.remote~ processor intensive?