help... live.remote~ burning a hole in my cpu

[3dot...]

so I thought heck.. I'd give m4l another go .. see what's new..

I've gone through the API devices in the Library..
and thought wouldn't it be nice to have those nice curve companding/smoothing features...
on each knob/button of the bcr..

so I grabbed the cc to signal transforming parts and the mapping parts from the original
and built a bank of 8butt/8knob as crude a max patch..
with the intention of having heaps of those on the set...
(mapping the BCR alone would require 7 of these devices chained)
and expanding on it.. with lfos etc..

so I've built it ...but only 1 of these devices in a set..
consumes 16% of my cpu... (1% for each knob/button!)

even before the knobs or buttons are even mapped to anything..
and it increases to 20% if I actually use those knobs..
'freezing' it don't help either..

I dunno about you .. but it seems a bit too much for controlling 16 parameters

(win7x64 Q9650 8Gb Ram 256samples MOTU 24 I/O)

I know I probably did all types of wrong but here is the patch :
http://dl.dropbox.com/u/639447/bcr2kCCmaster_0.4.amxd

you tell me.. do I have to get rid of all the live.remotes~ and switch to something else?
I realise they work at audio freqs..
so maybe I should use live.object ?
any other advice...? help would be much appreciated..

(I'm not really savvy with all of the max objects
so I generally use what I know unless I hit the wall..and then I learn some new ones..)

[luddy]

The remote~ objects only work at their input rate, i.e., the rate of whatever is feeding them. If you take a look at some of Robert Henke's patches (free to download, then you have to do some wading because they are pretty big patches) you'll see some nice examples of moderate downsampling on the inputs to remote~. Actually I think that some of the included patches from Ableton (those that come with M4L) have this kind of thing too. If you drive the remote~ at audio rate, it is pretty heavy-duty. i tend to think this has more to do with the parameter being controlled being modulated at audio frequency than with live.remote~ per se, but anyway it's true that it's easy for it to get out of hand.

-Luddy

[3dot...]

The remote~ objects only work at their input rate, i.e., the rate of whatever is feeding them. If you take a look at some of Robert Henke's patches (free to download, then you have to do some wading because they are pretty big patches) you'll see some nice examples of moderate downsampling on the inputs to remote~. Actually I think that some of the included patches from Ableton (those that come with M4L) have this kind of thing too. If you drive the remote~ at audio rate, it is pretty heavy-duty. i tend to think this has more to do with the parameter being controlled being modulated at audio frequency than with live.remote~ per se, but anyway it's true that it's easy for it to get out of hand.

-Luddy

I'll look into Roberts patches..
see how I downsample before the remote~
I really only copied the bpatcher from the 'building blocks'..

[3dot...]

well ..checked Roberts' lfo-zero..
he uses downsample~ with a value of 64 samples..before the remote~
tried it...
no change..

each live remote~ in my device is hogging cpu..

otherwise I'll check live.object/observer ?