FriFlo

I try to build kind of a bridge between Cubase (midi) hardware devices (midi) and Lemur on iPad (OSC). For this purpose I want to have one patcher (or bpatcher) available for any cubase midi track. On the hardware midi side I convert the incoming midi data to internal max sends. On the iPad I have only one template with different controls, that can be hidden resized, labeled, etc. All of this happens inside one patcher per track with visual controls available. However, all the label names, settings, (...) are saved within the bpatcher. So far everything went well (except for udp send problems as described in my other thread). But now I see, I have to use that bpatcher as an embedded version. Otherwise all the pattr objects will save the same data, where they are supposed to save individual setting. For a large cubase template i will have to copy that bpatcher 100-200 times. Only 3 Tracks make saving really slow now and I am worried that the final patch will take ages to load and probably get slow and create midi latency.

So, my question: How do you handle that kind of situation? Again: It is important, that the settings are saved individually per track. It is also important to have visual access to each track setting (therefore bpatcher).

I try to build kind of a bridge between Cubase (midi) hardware devices (midi) and Lemur on iPad (OSC). For this purpose I want to have one patcher (or bpatcher) available for any cubase midi track. On the hardware midi side I convert the incoming midi data to internal max sends. On the iPad I have only one template with different controls, that can be hidden resized, labeled, etc. All of this happens inside one patcher per track with visual controls available. However, all the label names, settings, (...) are saved within the bpatcher. So far everything went well (except for udp send problems as described in my other thread). But now I see, I have to use that bpatcher as an embedded version. Otherwise all the pattr objects will save the same data, where they are supposed to save individual setting. For a large cubase template i will have to copy that bpatcher 100-200 times. Only 3 Tracks make saving really slow now and I am worried that the final patch will take ages to load and probably get slow and create midi latency.
So, my question: How do you handle that kind of situation? Again: It is important, that the settings are saved individually per track. It is also important to have visual access to each track setting (therefore bpatcher).


create-one-max-patch-with-hundreds-of-bpatchers

By the way, the bapatchers also contain bpatchers within them ...

don't use embedded versions. use argument creations in your bpatchers, you can access those inside bpatchers either with the [patcherargs] object or with #1 #2 etc variables. You can use those variables to listen to different midi port/controller numbers etc. You should also give a look (if you didn't already) at scripting messages with [thispatcher] (see helpfile) in order to create new objects and set their placement, as this will automate the process which can be really usefull for creating that kind of ui things.

Though, are you really sure you need the ui, if you have already the Lemur ? maybe it would be easier to do thing with [poly~] if you don't.

don't use embedded versions. use argument creations in your bpatchers, you can access those inside bpatchers either with the [patcherargs] object or with #1 #2 etc variables. You can use those variables to listen to different midi port/controller numbers etc. You should also give a look (if you didn't already) at scripting messages with [thispatcher] (see helpfile) in order to create new objects and set their placement, as this will automate the process which can be really usefull for creating that kind of ui things.
Though, are you really sure you need the ui, if you have already the Lemur ? maybe it would be easier to do thing with [poly~] if you don't.


Thanks for the answer! I couldn't wrap my head around using the args, but by looking I found pattrstorage which solves all of my problems.

Create one Max Patch with hundreds of bpatchers