Dynamically call patchers into a patch
Hi,
I'm trying to create a standalone patch that will apply three different effects to video, where the user can choose each effect from a drop-down list. To save from having the whole patch load at once (the effects are quite extensive), is there a way of having the effects saved off in discrete patches that can then be called in to the main patch when selected?
Hope this makes sense! Thanks,
Kanisi
try the message (script newobject thenameofyourabstractioninafolderaxknows) to the object [thispatcher]
like this. in general have a look at thispatcher help. you can also make connections if you add a scripting name
afaik it's not an easy thing to do in Max. You can :
-have buttons opening new patches through the pcontrol object
-use bpatchers,
-disable some of the workflow with switches and so on.
But i don't know if there is really a way to do simply what you want to do, ie. having patches waiting in the background, unactived and saving some of the machine power. The object doing this in msp would be mute~, but it's buggy and maybe even obsolete (or at least i've been told so), anyway it does nothing as far as jitter is concerned, and i don't know if there is something similar in jitter.
That's all i know on the topic, and admittedly i would gladly receive some enlightenment !
edit - crosspost ! yeah, didn't think about thispatcher, it's a little similar to the bpatcher method, but it can be expensive ?
Here's an approach I've used to do this with bpatchers. The filepath magic for standalones and collectives comes from the thread credited in the patch.
As long as you save your bpatchers into the BPs folder and refresh the filepaths, you can load dynamically from the menus. Scripting also takes care of connecting the bpatchers to the rest of the patch, represented by [p process]
Cheers
Roger
The problem has been adressed in the above posts, but given you are likely to be using Jitter(?) and despite rogers useful patches (for example) I would suggest at least considering the following as an alternative...
Jitter makes relatively small claims on cpu cycles when the matrix processing chain is not polled (ie by a qmetro). To this end, you could just route the matrix data and qmetro to (and from) relevant (loaded) subpatches rather than loading them when required.
I've attached a rather quick hack of Jitter tutorial 6 to hopefully illustrate the concept.
`
I have done this for similar reasons (I just want to load certain patchers on the fly inside a main console patcher). The way I did it was as follows.
My main patcher contains a bpatcher whose script name is 'CurrentSong'
The main patcher which is always open has the following in a corner:
[receive ConsolePatcher] ---> [thispatcher]
I.e, two objects, one of which receives messages for 'ConsolePatcher' and then sends them to [thispatcher].
Then in some other patcher (wherever makes sense, I have it in a patcher that receives MIDI program changes from an external device and then maps the program change message to a patcher name), I have two objects
[script sendbox CurrentSong replace $1] ---> [send ConsolePatcher]
and this replaces whatever was in the bpatcher called CurrentSong with a new patcher whose name is represented by $1
Seems to work perfectly.
Thanks guys, I've got plenty to go on there! Sorry for delay getting back, I was away on a break until yesterday. Tough, I know! I'll let you know how I get on.
Appreciated,
Kanisis
I know this is old thread, but just wanted to say thanks to @dhjdhjdhj for his suggestion of replacing the content of bpatcher box.
p.