Implementing presets (pattr or other) in a modular environment w/ bpatchers
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).
" 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.
----------begin_max5_patcher---------- 1664.3oc6ZrrbaaC7r7WAFdIoyn3gukjuz1i8VuGmwCHIjDRo.z..ZYkL4eu K.Ho.kI0CakzDWMdroDVvEK12O7WuYjWF+IhzCcG5inQi95MiFYVRuvn5uOx aE9o7RrzrMOFYCO6ydisfdDKX3UDCD0FdyxJxSJyZqQNqtFqxWRYKdPPxU1y bR5s9iQAyz+MZRymQep9MXUqnrRhxbz90KRKLnFnhOD4sai7J096bNmoZIu+ TPwkdNPjzuXfDDbquKERD0W+56OraZI4QhPR4LyKLtdc750NKOx4UzLsOyMH Jcb6RTlcof1kDjGoMu+tMhE.eRALoJgk1eZZpmE32to4v2wDimZ4hSi0Ohi0 2GTXRxNFIHTWTxy+GRgC6YjGeMgQYqEDIgovpZ5nEbAYNtpT8P+LqtvmiyIC 9x8JCF4sPPK3LMQz4M0K2bbeDEjXtactLlcvvq64kkv8nRlgEZ9ZVoAIgM.U bdYWPshRPoGynqvJhhZI1P+VjRWsVPYpNGDggAbrTlK3kkcPkExi8.o.j14j MzB0RCtbYkv1oqaDAds7nB5BhT0cMEdgr6JcrhcUCcsl6r9dV047Uq.cfFD1 wFFWo3fggRfJnEr2oPavLERwQBxBpTQDn68TZ6568PYj4bAAkKHf5DaA.Q7k EvO26cK5uE7LfyrEgQYUKFiJoLPgTiH0RBBTf.jtDqbvFUhvk.pJ1hHOslKs 6FirTibKb3qPR9JxFvnkfHkRB58xpLiYLfGNibu2u4dofyjjyqrxxDG.83aJ Hzn4Mw7HLXp9Q5TG8vm4gJvAfiWpfDutuwycUcX2UVnhEYc0Z5yQVCjucyMM eX7KTmnim9m4suJNNx22exrjCqz3cXl7Teq4cj9QxraS5FA3v7XKeTsccsuB vfv42N3vUbDMr3H9zEG86Tz5YVp3VO2idFOdTsEgkh6bQGYU7sPBCPepERqz 7hHWqVkQDCIWqotiXZDYDT1H1I96G29LkZZWqf.KCqu6CHzR6RQBfbAOOOX8 0tugTWYZ3KVl9iyXZV7LswTTZuFSFCIsNEdA4HRlvnYVCJSJAoydkhlgMhlL rQTvkvHRhejT7.bTvU6A88mlUorA45ynJujBwubUQ802bei9olS3umo1Qzgz YRX32NnLYZjlkpQaTrlsN46kI5gBGujuAAgvJKrQKyHnJcfwMT0RjqhB52GL vW3g0ghrg5hrJRFq6nfWRbufeIi6cHlugkWWkv6jHHwvRZNUgzjOJGyzoxvZ kITVaxJYTVgN2kBH3fTmYTqJ8fRonSyROvUNEG8BjSSdCJlHHaYM4DDeNHEt 25DERpz5RAjMRZAAfzjuHjG6B5iDIRhoEtqBR0V4rLWmjNH9zLhwnMKoPhlP ZpTEjpJTuFtzpJ7dcBoi0oxtgenTPSOlL1lCZriHVmwz4aJ5+FTFC7cSd+vy bbYIXv0V5vQhRlZyewOzgud5QIc3qS+0Ly9mkA3fYlGG8CKEuj21o3McRrIE uYCmhG5OpCS.2dPs+t6fBXu6NaQAGVXYS2q1OQZxqMquiUB0ApfJ5BWAE3Db VGx3LSLrWEo+KJr5TDiAt9k9gXzE9ShQ2tl6oiONPurLbLM79EFRdkHu4xW6 QoaE159rAguaa04GaUm2aeKoEEc6rnsAtEq4.Wsl7lZZWgMO4XaZxVukFyv8 kaETolmVzQA7fZcm60M5DutIm308XTbc0OMsj9XVle8B013i2V5ynWp8RDG3 vG5PWTxyvk0oL19t8zx1a1wDM+0J3ecSdABSzyjWbVsuTKcm7xzydxKgWm7B vDmUWClMhazL6iP+qSd45jWt.k3v3Jfps84AJ9bIVZFUhTWgYMUWWJJB.ggs qqWss.W6l2UHac0n2h9KEpfSj5Y4HH3xsHf6qmiSFIGWI2G2.lghr.kXn31l wuXvm1zrTNFN3BSuOx.xHOmH0s9XtfuxLPF6nY3L3Tx1hlSERnJ50jb57s5C PShVTujRDZyusZJutvZM8oKSW1TPscqlCVW12talcTO29Rm0iwLNLzZ+N4kO pm3qsR46VqTNxz7NRqTRsiwa10NobY6jhks56esSJCxihsoWEmbcZYWlVojF XlVVb5YzJEHz2o0JkZokcd+Aowus5kRv+a5kxLGGSWakxqs2BoeeakRb8+qM A1Bnr9Kc+RP5OssSI8Z6T9YpcJFIw9MHPyr1qw.60Tfm2PfgZF.bNe6l+ETz DN9H -----------end_max5_patcher-----------
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.