Pattr, bpatchers and data comms

    May 17 2018 | 7:23 am
    Hi all,
    I'm really finding myself swimming in a sea of unknowns - being not that great with Max. Slowly getting there thru reading this forum and 100's of help pages.
    Anyway. After trying in vain in a few sessions to get the following working, I thought I might run it past those more knowledgable than myself... :)
    See attached little project (3 patches)
    Some parts I've figures out nicely. The tabbed interface using really simple scripts to show / hide the two different windows. One window is for setting variables for each of the 10 layers, and the second window will be a UI for some actual playback. The second window is just a placeholder for now. I just was mucking around with getting the tabs working nicely.
    My question revolves around pattrstorage, autopattr and bpatcher. I've read thru a tonne of threads here, and downloaded a few example projects. I even essentially ended up copying one, only to see extremely different behaviour in mine.
    So I'm guessing that I've missed something entirely.
    What I'm trying to get is 6 sets of variables - saving them in the six preset slots. Each set of variables contains some "global" variables (in the master patch) - which work all fine. But they also need to store the variables inside the L# bpatchers. (And all the variables need to be seen in the P# bpatchers - thats part 2!
    At the moment, the variables don't seem to be stored for each layer. I'm guessing I'm just not referring to them properly / missing one key piece of information... can anyone work out what it is?
    Second - is there a way to NOT have the pattrstorage store which layer tab is selected? I'm guessing thats occuring because of autopattr... but when I tried different ways to exclude it, it just didn't work. Thats secondary and something I'll probably figure out myself... but just trying to save a little time.
    Hope this is clear. I've tried to make the patch fairly readable.
    Any help is very much appreciated. I'm here if something doesn't make sense.... :)

    • May 17 2018 | 2:21 pm
      You have to refer the [preset] object to the named pattrstorage. Otherwise preset uses its own storagesystem. All interface objects that don't have a scripting name will not be included in pattrstorage. Maybe this will help explain:
    • May 18 2018 | 10:16 am
      Oh many many thanks. I was going round in circles. I don't know how I missed this in help files - but it works a treat! One quick other question... now you've fixed my issue... I'm wondering a little bit more about the way the data is stored / read. The data in each of the bpatchers is stored / recalled great. But what if I wish to grab the data stored from L1 in P1, L2 in P2, L3 in P3 etc? Say I just want to the hi/low values from one of the rsliders inside P1 that is stored from the UI object in L1. Given the way I've set it up, is there a simple way of doing this? Or have I set things up in an overly complex / messy way? Any ideas appreciated. Cheers. B.
    • May 24 2018 | 3:55 pm
      I'm not sure what you are trying to accomplish eventually. Because the whole idea of a pattrstorage is to have presets that can be recalled to the same object. So say you have two integer boxes, one called Hi, one called Lo, you don't need to build some construction with layers and multiple versions of that box, because you can store multiple presets and recall those values to the 2 integer boxes. There will surely be a way to grab presetdata from one number and store it to another one, but that will be more complicated i believe.
      Summary: The preset slots of pattrstorage + preset function as your "layers".
    • May 25 2018 | 12:42 pm
      I see what you're saying... What I'm trying to achieve is 6 themes (what I'm using 6 preset slots for) then 10 layers - for each of those 6 themes Those layers all have a bunch of variables associated with them.
      If you can suggest a better (or even just another idea) for setting it up - I'd love to hear it.
      But I've managed to get it all working - and slowly cleaning things up / making things as efficient as possible. I've got a small abstraction working that can pull the data from a parallel patch quite nicely... so I can grab the data in L1 (layer one) of Theme 1 in P1 (Player1) for theme 1... and L6 inside P6 in Theme 4 - or whatever :).
      At least for a beginner, this was quite a challenge. But somehow have something that seems to be working well.