Please, someone confirm or deny

[trevox]

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

I should really begin reading all follow up posts before replying!

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.

[trevox]

If you're interested, here is what I created as a morph LFO. I hadn't included any phasing yet, so the sine is actually cosine etc etc, but that can be modified simply enough....and apologies, I can be a pretty messy patcher!

http://dl.dropbox.com/u/30280761/LFO_multi02.amxd

[3dot...]

I should really begin reading all follow up posts before replying!

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.

.. hey.. gate~ wired to the knobs is a great idea!
hadn't thought about that..
gonna try it out tommorow ! (it's sleepy time)
thanks for that !

[3dot...]

If you're interested, here is what I created as a morph LFO. I hadn't included any phasing yet, so the sine is actually cosine etc etc, but that can be modified simply enough....and apologies, I can be a pretty messy patcher!

http://dl.dropbox.com/u/30280761/LFO_multi02.amxd

I'll be all over it ! thx !

[habeeb24]

I don't observe a linear relationship between number of max devices and cpu use. its not that simple. I have not carried out the empty device benchmarking test, the results wouldn't help me realise my ideas.

[oddstep]

not true for me. adding max for live to a liveset does increase the cpu overhead - but I don't observe a linear relationship between number of max devices and cpu use. its not that simple. I have not carried out the empty device benchmarking test, the results wouldn't help me realise my ideas.

Habeeb24 do you think in exactly the same way as me or are you simply copying my post as a form of efficient participation. Either is cool.

[ark]

FWIW, Max 6 includes a (major) new feature named gen~ that makes it possible to generate low-level machine code for MSP patches. So for many signal-processing applications, Max 6 will be capable of using much less CPU than Max 5.

Live doesn't officially support Max 6 yet, but I can't imagine it will be too long before it does.

[3dot...]

as I understand ..
gen is gonna cost EXTRA $..aside from the max6 update...
right?

[ark]

as I understand ..
gen is gonna cost EXTRA $..aside from the max6 update...
right?

USD 50.

[synnack]

Actually that brings up a question. Will devices made using Gen work for users who didn't buy Gen? Hrm.

[pid]

"yes"

(that is from horse's mouth)

just users with Max6/M4L2(?!) with NO 'gen license' will not be able to build/edit anything 'Gen', but they will be able to run and use patches / devices which happen to use 'Gen', and even 'view' the 'Gen' code.

personally i think that is rather fantastic / gen-erous of cycling74.

[synnack]

"yes"

(that is from horse's mouth)

just users with Max6/M4L2(?!) with NO 'gen license' will not be able to build/edit anything 'Gen', but they will be able to run and use patches / devices which happen to use 'Gen', and even 'view' the 'Gen' code.

personally i think that is rather fantastic / gen-erous of cycling74.

Cool. Conceptually one step closer to a free M4L runtime.

[3dot...]

personally i think that is rather fantastic / gen-erous of cycling74.

I don't..
it's part of the architecture and shouldn't cost more...
separating it is a simple scheme to get 50$ more on the upgrade (it's being pushed as the biggest feature in Max6 after all)
but it'll result in people not buyin it.. (Max is deep enough as is..).. which means less profit.. and of course..less adoption of this new tech..
to be honest..sick and tired of all these addons..
I don't get this..
just include it in the max6 global upgrade ..charge 25$ more a piece(since EVERYONE upgrading is gonna get it..)
don't make me buy an addon for the addon...
imo it's foolishness..
and I'm an expert of foolery..

[pid]

well, i have a lot of sympathy with 3dot. i loathe the whole intro/suite/basic/pro/advanced versions and addons worlds of commercial software too. for a start, such multi releases should be known as 'normal', 'shit' and 'shitter (what do you expect at that price)'... however, i totally understand them as necessary in the commercial market.

anyway, not gonna defend the gen costing money thing. not my place to. but i will say that firstly, cycling are the least irritating on commercial issues company i ever came across and i never feel it has been overpriced (well, not too much!), unlike "live" which has (even though i love it). And secondly, the case with "max" it is a little different...

for starters, max has always been multiple apps in one. until the release of max6, you could buy max alone, or max and msp, or max and jitter, or max and msp and jitter. ie, the 'data', 'audio' and 'video' parts separately. back in the early 90's and later, max with a mainly-midi app, used a great deal by hardware synth users etc.

they have finally accepted their 'multimedia' existence with max6 by calling the whole thing "Max" and including all parts of previous sections as one (you cannot buy them separately anymore) and making it all a hell of a lot cheaper. gen is a brand new thing, it does some radically different things (not just for Max, but game changing in terms of media software in general), and i am actually dumbfounded at how cheap it is. AND, 'Max6+Gen' costs the same as what 'Max+MSP+Jitter5' used to cost. good huh? so actually, in order to make it 'stand out' and make it an addon, they just lowered the price of everything. i think that is cool way to go about business.

also do not forget, max6 without Gen also brings some amazing and cool new features to all areas of data, audio and video that might have got lost a bit in the news of 'gen'. i mean i would have paid upgrade price for 'dict' and 'filterdesign' only, let alone all the other amazing stuff.

just my small (large) two c's...