live.remote~ processor intensive?

Nov 4, 2010 at 1:48pm

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.

Nov 4, 2010 at 7:11pm

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

Nov 4, 2010 at 10:27pm

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.



You must be logged in to reply to this topic.