live.remote~ processor intensive?
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.
The cpu load of live.remote~ greatly depends on the target, as shown here
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
Here’s the log for those changes.
-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.
-A