how to have a bpatcher that can save presets for its parent patch.


    Nov 29 2015 | 5:44 pm
    I have a number of different bpatchers that do different things, i.e. not instances of the same .maxpat, but different ones - i'll call these MODULES (MODULE_BPATCHER_A,B,C,D etc.) And for each module I want to be able to manage presets in a particular way, i.e. they each share an identical UI to load/save presets, also a dropdown which is automatically populated with the contents of a folder (different for each module) etc.
    I have a small network of nodes that do this preset management (load/save/populate dropdown box with contents of folder etc - attached at the bottom of this post) and currently I copy paste this into each of my module bpatchers (which also each have an autopattr), and it works fine. But of course maintaining it is a PITA. Is there a way I can have this custom preset management network in its own bpatcher, which I embed into each module? (i.e. to tell the preset_bpatcher to store everything from one level up, and then recursively down again).
    this is what I currently have: MAIN_PATCH ....MODULE_BPATCHER_A (contains my presetmanager patches copy/pasted straight into it) ....MODULE_BPATCHER_B (contains my presetmanager patches copy/pasted straight into it) ....MODULE_BPATCHER_C (contains my presetmanager patches copy/pasted straight into it) ....MODULE_BPATCHER_D (contains my presetmanager patches copy/pasted straight into it)
    this is what I want: MAIN_PATCH ....MODULE_BPATCHER_A ........BPATCHER_PRESETMANAGER ....MODULE_BPATCHER_B ........BPATCHER_PRESETMANAGER ....MODULE_BPATCHER_C ........BPATCHER_PRESETMANAGER ....MODULE_BPATCHER_D ........BPATCHER_PRESETMANAGER

    • Nov 29 2015 | 7:17 pm
      Since the UI objects appear not to require the pattrstorage to be in your proposed bpatcher, I'd just move the pattrstorage object into the parent module patch and connect it via an outlet in the bpatcher.
      If you want the pattrstorage to track child nodes in subpatchers or bpatchers you should enable @greedy mode as needed.
    • Nov 30 2015 | 1:40 pm
      Ok thanks. that does make sense. In this case a solution like that does work (and is what I'm doing now). Out of curiosity, is there a way for a subpatch to store the settings of its parent (one heirarchy up) and siblings?
    • Nov 30 2015 | 7:26 pm
      Not that I'm aware of.