Please, someone confirm or deny

[3dot...]

yeah.. I was referring to remote~ ..
the actually snagged the bpatchers from the m4l tutorial patches ..
and slightly modified
also I had downsampled before outputting to remote ~
that didn't help much ...

I wanted to have morphable lfos for 8 buttons and 8 knobs ...
...seemed like remote~ would be the right way of doing it..
I used the implementation Ableton used in their patches..
guess it's not as simple as it superficially looks..

and as a sidenote.. most of us are musicians ..not pro programmers ..
therefore ..basic operations for control and instrument creation and musical expression
should be simplified ...
so we can build and continue to create without hitting into a wall..
I can't be bothered to throttle Live internally..

[trevox]

@trevox, '3dot' was referring to multiple [live.remote~]'s, and yes, these can be a cpu hog. the reason? they are audio rate. which is fantastic if you need it here and there. however, often you do not - you simply 'downsample' the data going into [live.remote~] and performance increases drastically. if you are controlling Live control-rate processes then the downsampled signal rate is still more than enough resolution and does the task at hand.

so, while i agree certain parts of m4l are cpu hungry, and yes, of course i wish for this to be greatly improved in future releases, this is another one of those examples where max (m4l) shoots itself in the foot with regards casual users, giving the power to do something but a little more knowledge is required to get the most out of it.

examples of all these [live.remote~] things are in the m4l examples and tutorials.

now sure, the whole preset and recall features i will admit are a bit messy and cpu hogging, largely to do with the way live works for adding everything to the undo queue etc. that is a known issue and apparently they will address it in future releases.

Ah, I misunderstood (well didn't read properly!) the post - sorry 3dot! I have used live.remote~ in some patches (not the ones in the template) and must check to see how they affect performance - I hadn't really noticed it being a huge hog, but then again, I wasn't really checking or using a load of them. I must get around to going through the M4L tutorials properly - I have used Max/MSP for years (I don't see myself as a casual user!) so know that side of things really well and I kinda figured out the specific live objects on the fly to save time rather than going through tutorials. That may be time well spent in retrospect!

[trevox]

yeah.. I was referring to remote~ ..
the actually snagged the bpatchers from the m4l tutorial patches ..
and slightly modified
also I had downsampled before outputting to remote ~
that didn't help much ...

I wanted to have morphable lfos for 8 buttons and 8 knobs ...
...seemed like remote~ would be the right way of doing it..
I used the implementation Ableton used in their patches..
guess it's not as simple as it superficially looks..

and as a sidenote.. most of us are musicians ..not pro programmers ..
therefore ..basic operations for control and instrument creation and musical expression
should be simplified ...
so we can build and continue to create without hitting into a wall..
I can't be bothered to throttle Live internally..

I had altered a patch called Advanced Operator envelope (created by ring (Simon Slowik) and all credit should go to him) before to envelope external midi parameters in hardware and remembered it's original use to remote control parameters in Live, so I decided to have a look to see what performance was like. I think I have made what you are looking for. It does use live.remote~, but I have 8 faders happily automated by a looping envelope at 1% (well flickers to 2% every once in a while)! You can also set the max/min values for each parameter and there is a map button for simple assignment, as well as an on/off button for each parameter. I can easily add options for more parameters too. Adding to that, you can draw your own wave. Is this along the lines of what you were looking for? I can send to you if you like...

[Spectrumdisco]

Like all the above answers, it will depend on the effects used and the confi of your computer.

[3dot...]

yeah.. I was referring to remote~ ..
the actually snagged the bpatchers from the m4l tutorial patches ..
and slightly modified
also I had downsampled before outputting to remote ~
that didn't help much ...

I wanted to have morphable lfos for 8 buttons and 8 knobs ...
...seemed like remote~ would be the right way of doing it..
I used the implementation Ableton used in their patches..
guess it's not as simple as it superficially looks..

and as a sidenote.. most of us are musicians ..not pro programmers ..
therefore ..basic operations for control and instrument creation and musical expression
should be simplified ...
so we can build and continue to create without hitting into a wall..
I can't be bothered to throttle Live internally..

I had altered a patch called Advanced Operator envelope (created by ring (Simon Slowik) and all credit should go to him) before to envelope external midi parameters in hardware and remembered it's original use to remote control parameters in Live, so I decided to have a look to see what performance was like. I think I have made what you are looking for. It does use live.remote~, but I have 8 faders happily automated by a looping envelope at 1% (well flickers to 2% every once in a while)! You can also set the max/min values for each parameter and there is a map button for simple assignment, as well as an on/off button for each parameter. I can easily add options for more parameters too. Adding to that, you can draw your own wave. Is this along the lines of what you were looking for? I can send to you if you like...

check this example :
http://dl.dropbox.com/u/639447/bcr2kCCmaster_0.4.amxd

[pid]

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:
http://dl.dropbox.com/u/2648006/3dot-down8.zip

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.

[3dot...]

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:
http://dl.dropbox.com/u/2648006/3dot-down8.zip

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.

hi pid..
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..
and mainly..
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..

[starkaudio]

Deny.

M4L is an open ended tool. You can always build something that will kill your cpu/memory. It won't keep you from shooting yourself in the foot. Even with an old/slow machine you can get great benefits from learning and using M4L.

Just because a tool may not be optimal doesn't mean you can't make interesting and inspiring things with it.

[3dot...]

Deny.

Just because a tool may not be optimal doesn't mean you can't make interesting and inspiring things with it.

no one argued that it's useless..
it's just like you said .
not optimal=not there yet. which is fine.. m4l is still an infant.
sure you can make fun/useful stuff..
but with some very annoying pitfalls along the way..

after going through the learning curve.. and really knowing m4l ..
you'd be faced with various issues of the 'environment'..
that have nothing to do with you as a developer..
has to do with how well Max/msp is integrated into Live..
and right now the answer to that would be 'badly'

cpu performance is only part of the problem (more like a symptom)

[kanuck]

i think what a lot of people fail to understand what max exactly is. It's visual programming. Some programs are cpu efficient, some aren't. Therefore, cpu efficiency is based mostly on the complexity of the patch and the skill of the patcher.

[3dot...]

Therefore, cpu efficiency is based mostly on the complexity of the patch and the skill of the patcher.

mostly is a key word here..

[starkaudio]

no one argued that it's useless..
it's just like you said .
not optimal=not there yet. which is fine.. m4l is still an infant.
sure you can make fun/useful stuff..
but with some very annoying pitfalls along the way..

after going through the learning curve.. and really knowing m4l ..
you'd be faced with various issues of the 'environment'..
that have nothing to do with you as a developer..
has to do with how well Max/msp is integrated into Live..
and right now the answer to that would be 'badly'

cpu performance is only part of the problem (more like a symptom)

Maybe I misunderstand, but it seems like you are advocating that people *not use* m4l because it "isn't there yet". Is that what you meant? Maybe I didn't understand you.

My point is this (aimed at the OP:)

1) M4L has limits.
2) It will let you shoot yourself in the foot. Be careful.
3) It's also an amazing creative tool.
4) You can only make your life more interesting by learning to use it (regardless of it's current limitations.)

I'd say try it out and have fun!

[maaz-eke]

yep, TX. I'm still into doing it

just '...is nice to know more things about bride before...' exhaustion of (money or time or inspiration) budget

[trevox]

yeah.. I was referring to remote~ ..
the actually snagged the bpatchers from the m4l tutorial patches ..
and slightly modified
also I had downsampled before outputting to remote ~
that didn't help much ...

I wanted to have morphable lfos for 8 buttons and 8 knobs ...
...seemed like remote~ would be the right way of doing it..
I used the implementation Ableton used in their patches..
guess it's not as simple as it superficially looks..

and as a sidenote.. most of us are musicians ..not pro programmers ..
therefore ..basic operations for control and instrument creation and musical expression
should be simplified ...
so we can build and continue to create without hitting into a wall..
I can't be bothered to throttle Live internally..

I had altered a patch called Advanced Operator envelope (created by ring (Simon Slowik) and all credit should go to him) before to envelope external midi parameters in hardware and remembered it's original use to remote control parameters in Live, so I decided to have a look to see what performance was like. I think I have made what you are looking for. It does use live.remote~, but I have 8 faders happily automated by a looping envelope at 1% (well flickers to 2% every once in a while)! You can also set the max/min values for each parameter and there is a map button for simple assignment, as well as an on/off button for each parameter. I can easily add options for more parameters too. Adding to that, you can draw your own wave. Is this along the lines of what you were looking for? I can send to you if you like...

check this example :
http://dl.dropbox.com/u/639447/bcr2kCCmaster_0.4.amxd

I had a look and can't really see where LFO's are involved. Looks to me like you want to create morphs just for knobs/Buttons on your BCR2000 and scale them differently for each parameter? The patch I threw together will control 8 paramaters anywhere in Live from one source (an LFO) - which is a what I would consider a morphable LFO! This uses around 1% which is similar (and equivalent) to what you have for one knob which is beginning to make sense now. I still think there is a much simpler way to do this that would use less resource - there has to be! If I get some time, I'll have a look.

[3dot...]

yeah I know.. I stopped developing it..
(so the lfos didn't make it in once I saw the cpu burn..)

but other than downsampling before the remote~ input.. don't see what else I can do..
tried asking around in the forum. looking into well built patches etc.
I guess using observer and object..is the only way to save cpu..
then having audio-rate morphable lfos idea is lame...
I'll rebuild it with max objects and forget about the audio-rate thing..

@starkaudio
... why would anyone shoot himself in the foot..even when presented with a loaded gun ?
shooting yourself in the foot is usually caused by accident.
or wanting to collect insurance.
you've got me wrong..
I'm not advocating against getting m4l for the sake of fun and learning..
heck I bought it and love it..
it's just that some things need to be said about performance..
simply sharing my frustration as a novice/noob..
I'm just telling it like it is (imo of course..)