thouldcroft

I've searched this out, and it seems like others have a similar problem, but it seems that everyone's questions with the pattr system are so diverse and there are so many features to it that I'm not 100% sure if this has been answered, so I apologize if this is redundant.

So I am building a modular system to teach my class modular synthesis, Max and creative coding piece by piece. Inspired a bit by Vizzie and also the parts of Reaktor that I like, I built these bpatcher modules that function as the modules of an modular synthesizer, and my students can then patch them together as they wish to create their own synthesizers.

The problem I'm having is building a module for saving presets. The standard preset object doesn't work, because all the UI items are within bpatchers. I thought using pattrstorage with an autopattr embedded within the bpatchers would work, and would allow me to use a preset object as the UI to the pattr system, but the problem I'm running into is that if I build a module with the preset/pattrstorage object (to reinforce the modular aspect of the system) I end up placing the pattrstorage at the same level in the hierarchy as the autopattrs, which from what I read is the reason I'm not able to get preset management with my bpatchers. However, I would really, really like to have the preset management UI encapsulated in a module, so that students can drop it into their master patch when they want to use it (or when we get to that point in the lesson).

Has anyone uncovered a way to work around this? I'm no expert at the pattr system so maybe I'm overlooking something? I'd even be willing to dive into preset management with JavaScript if it would work (I've done some scripting in Max with JS but never looked into preset management with JS, not sure if it's even possible).

Has anyone uncovered a way to work around this? I'm no expert at the pattr system so maybe I'm overlooking something? I'd even be willing to dive into preset management with JavaScript if it would work (I've done  some scripting in Max with JS but never looked into preset management with JS, not sure if it's even possible).

implementing-presets-pattr-or-other-in-a-modular-environment-w-bpatchers

" However, I would really, really like to have the preset management UI encapsulated in a module, so that students can drop it into their master patch when they want to use it (or when we get to that point in the lesson)."

This may preclude the use of the preset object per se, but maybe a solution is that the preset management UI is encapsulated in a module/bpatcher while the actual pattrstorage itself resides in the 'main' patch(?).

Hmm.. that is an idea. That would require the students to use a "pre-built" blank patcher to work with their modules that would house the pattrstorage. Having essentially a strictly UI bpatcher might keep the spirit of modularity. I might just hard-set a preset bar in a "blank" patcher for them to start with, similar to how you have you preset management set at the top of the window when working in Reaktor. I'll give the preset UI module a shot first, and try and hide the pattrstorage.

I have a quite similar problem : i would like to try and succeed accessing pattr-exposed parameters across patchers. The general problem of pattrstorage is that it will only see this patcher level, and children patcher levels ; not parents patcher level ; which is a bit misleading because the pattr can bind to (with the @bindto attribute) any opened context where the bound address exists.

This here explains how to access other patchers objects with a [pattr] using @bindto. It should be feasible to have local version of everything and thus effectively have a pattrstorage in one subpatcher which could save objects bound to other objects in distant patchers. It is quit eheavy though, because you need a duplicate for each object which state you want to save, and a [pattr] with the correct @bindto adressing.

However i hope that i still miss something, and that that binding thing allows to streamlessly save states of distant objects.

Hey
I have a quite similar problem : i would like to try and succeed accessing pattr-exposed parameters across patchers. The general problem of pattrstorage is that it will only see this patcher level, and children patcher levels ; not parents patcher level ; which is a bit misleading because the pattr can bind to (with the @bindto attribute) any opened context where the bound address exists.

However i hope that i still miss something, and that that binding thing allows to streamlessly save states of distant objects.


Thouldcroft, the method you described of using a "blank patcher" (that contains the pattrstorage) and then adding bpatchers as you like with named pattrs within is what I do.

It works perfectly for me in a project of mine where all bpatchers are scripted into existence as desired within the patch containing the pattrstorage.

what about writing custom presets into a file.

the custom preset could be built around a [zl reg] and each list of parameters would start with an ID of the module instance.

Implementing presets (pattr or other) in a modular environment w/ bpatchers