vichug

What is the best strategy to manage presets inside a Max project, comprised of several Max patchers running in separate opened patches ?

This might appear as a strange question indeed, you could ask why not simply using one main patcher and several subpatchers. Well it's because i've been told that you can take advantage of multicore processing by running several patches communicating with sends~ and receives~ rather than one patch encapsulating everything ; from quick experience right now it seems to be the case, i have 10% cpu difference in using max poroject and separate patchers, or all abstractions in the same patch.

But : i use pattrstorage to manage everything preset related when it's just one patch. And when it's several patches, i don't know how i could do this... For now it just doesn't work, i can't access other patches with just one pattrstorage. What is the best way to handle this ? Multiple pattrstorage, with just as much presets files ? This seems quite unhandy... Is there a built-in preset system in the max projects ? Or did i overlook something with pattrstorage ?

(I doubt the 10% cpu increase when using one patch is solely due to the pattr system beeing active, right ?)

now a question :
What is the best strategy to manage presets inside a Max project, comprised of several Max patchers running in separate opened patches ?

(I doubt the 10% cpu increase when using one patch is solely due to the pattr system beeing active, right ?)


max-projects-the-pattr-system-and-managing-presets-in-separate-patchers

> Multiple pattrstorage, with just as much presets files ?

That's how I do it. The master patch sends messages to the presets in the node patches.

I haven't looked very deeply into the issue so there might be more efficient ways and I'll be glad to hear about 'm too. Next time I start a big project I'd like to do it better from the start.

> Multiple pattrstorage, with just as much presets files ? 

That's how I do it. The master patch sends messages to the presets in the node patches. 

I haven't looked very deeply into the issue so there might be more efficient ways and I'll be glad to hear about 'm too. Next time I start a big project I'd like to do it better from the start.


hm okay thank you... i don't really like this, cause it just makes everything more complicated, e.g. for preset interpolations, especially since i'm using pattrstorage to send remote messages to pattr-included objects, and i don't think it will be possible this way, or it will make everything more complicated. I'll try to see if there is another way...nothing as practical as pattrstorage i guess.

look up [pattrmarker], maybe you can make some use of it

looking the docs i thought it would be exactly what i need, but...

it's bugged ! on my max 6.0.8, wenever i instantiate it, max window says 'unknown external object type'... am i the only one ?

Anyway, trying on max 5, it doesn't explicitely allow a remote pattrstorage to store presets about objects in another patcher which has "pattrmarker" in it, thoughyou can access those objects through said pattrstorage, which is kind of weird.

hey
looking the docs i thought it would be exactly what i need, but...
it's bugged ! on my max 6.0.8, wenever i instantiate it, max window says 'unknown external object type'... am i the only one ?

Anyway, trying on max 5, it doesn't explicitely allow a remote pattrstorage to store presets about objects in another patcher which has "pattrmarker" in it, thoughyou can access those objects through said pattrstorage, which is kind of weird.


ok - the bug was because i had an old version of Jeremy Bernstein's pattrmarker in my searchpath. Now that it works in max 6 i see there's the same problem as in max 5, ie pattrstorage can't access other patches that are "pattrmarked", even though it can communicate with them thanks to an object's global name.

Max Projects, the pattr system, and managing presets in separate patchers...