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.

#53091
Nov 4, 2010 at 7:11pm

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

http://cycling74.com/forums/topic.php?id=25139

#190930
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.

-A

#190931

You must be logged in to reply to this topic.