I should really begin reading all follow up posts before replying!3dot... wrote:hi pid..pid wrote:hi 3dot.
it is a great patch.
in your [p bcr2000_knob] subpatcher you use the "M4L.SignalToLiveParam" BPatcher abstraction as is. yes, it would be nice if it was easy enough to just have all these API abstractions that come with the distribution be more easy to suit to various different needs.
ultimately though to use so many live.remote~s and M4L.chooser's i would programme your own stripped down module for use in each of your button setups. use the original m4l.chooser, but ask yourself if you really need all those options on the signal chain towards live.remote~? maybe ditch a couple of the more expensive ones?
what i would do is further downsample that entire chain using poly~. i have made a quick (untested, but should work fine) example of how one might go about doing this. should save you a lot of processing and still all work fine for your purposes.
download just max patch here:
alternatively, do you really need signal rate computation in your chain here at all? could you not just make some simple control/scheduler rate stuff using [metro] and [line] and various math objects? signal rate is fantastic and desirable, but not always necessarily needed.
there were some needless loadbangs here and there, but other than that pretty streamlined.
just to reiterate, for someone saying they are a casual patcher, it is a very cool patch. i enjoyed looking into it.
thank you so much for the kind words..
I love patching... hate troubleshooting..
this is why I have this love/hate relationship with m4l..
I build.. then hit a wall ..
and if I can't easily get over.. I tend to leave m4l for some time..
I currently have something like 10 pretty robust m4l projects..
which I plan to continue when m4l gets its ish togethter..
(in my mind.. m4l is supposed to put a stop to 'workarounds' outside the "Live environment")
..thought about using poly~ ..I need to learn it..
at the current stage I'm going over the js tutorials..
then plan to go deeper into mxj..
the reason I chose a to use all that stuff before the remote~ is..
I wanted control of the 'curve'..
I thought that patch was great ..
and wanted to have that for any single knob on my hw setup..
the plan was to integrate an seperate lfo that can be enabled for each knob..
also thanks for the example !
I'll go over it..
I agree with pid - looked a little further into your patch and there is a lot of audio rate signals sending contant streams of data which is where the problem lies. I feel the tutorial patch itself would need be stripped down - maybe figure out some way using a gate~ object or something to stop sending constant stream of data and only send when you are physically turning a knob - like is the case with non-audio rate data.