Bpatcher, Sendbox Replace, Pattr, Pattrstorage, and some things not loaded...
Hey all,
Little snafu I came across on a project I've been working on. I recreated the problem in a little three patch set attached to this message. It involves bpatchers.
I have a main window with two bpatchers in it. A drop down menu can change the patches in the bpatchers. There is a pattrstorage object and pattr bindings to store all of the data.
The problem is this: When I save a preset to a file, all of the information is stored in the xml file. However, when I recall the preset, the main patch changes, but the bpatchers load on their default values. I'm thinking this is something with the messages not getting to the bpatchers since they are loading.
If anyone has any insight on how to work around this it would be great. Thanks a bunch for your help.
Chris Roode
Just making an update for the record. I found a workaround that solves this problem to my liking. I am still tweaking it. While researching the forums I found that this question has been asked before, but I didn't feel the solutions from the past worked with my project.
The problem is with the pattrstorage object. When recalling the preset, the umenus that replace the bpatchers cause the pattrstorage object to drop the following parameters from memory. Since they are not in memory, pattrstorage simply cannot assign them. pattrstorage will not wait for a bpatcher to initialize a new patch before continuing.
Therefore, I have found a workaround to get the rest of the parameters in the bpatchers:
First, do the read command and load your xml file.
Second, load the patch you want (1 in this case)
Third, deactivate all of the umenu objects that replace the bpatcher (use the message below)
active slot1value 0, slot2value 0
Fourth, with the umenus deactivated, load the patch again (1). This will load what is in the bpatchers, but will not do any replace commands messing up the process.
Finally, I'm new to pattrstorage, so I decided to activate the umenus again.
There are still some problems with this method that I am trying to work around. On a first shot, it didn't work when all of the messages were tied together in a single button. However, when I split them apart and gave each step a chance to complete on its own, I loaded the bpatchers and parameters inside all together.
So there is still a problem to solve. How can these steps be automated without overlapping. I am working on that and will post it when done, but if anyone has suggestions, feel free to post.
Rock on!
Chris Roode
Hi Chris.
Would love to know if you find an answer I am struggling with the same thing myself.
Thanks Lee
The workaround that I described above is the best thing I found. I'm thinking that since there is so much going on at the same time when a BPatcher loads itself because of a pattr object, messages stack on top of each other and get lost. So you have to load the BPatchers first, then use a second command to load the preset of the subpatcher.
Couldn't figure out anything more streamlined. Did I mention I am learning how to program on the iPad.
yay, presets recalled by pattrstorage not being able to wait for other presets is sometime a mess... i worked it around once by creating pattrstorages inside each bpatcher, and having all a system creating automatically json for each bpatcher, all json saved in a folder created automatically when saving a preset with the parent pattrstorage. Such a mess...
Hi Chris. I played about with your idea and got it working found a way to make it a bit easier. Instead of sending a [read] message to the [preset] box I have a graphic for load going to a [opendialog] this is connected to a [set $1] message that is connected to a [text edit] box then out of its first outlet it goes to a [route text] box then in to a [read $1] message. attach the last outlet of the [textedit] to a button and then send the button to the first inlet of the [textedit] this insure's that the text is sent. So I no have a save (write and store 1, write has a delay on it) load (attached to above mentioned) and apply (attached to a 1 message) attached to the [preset].
so that's the first stage complete my effects have all loaded up into the correct channels. For the next stage I have a [checkbox] attached to gates that block the replace bpatcher messages, I have inverted the [checkbox] value so that on is 0 and off is 1(using [select 1]) then I have a second load graphic attached to the button that is attached to the [textedit] this reloads the save file without the user having to locate it again. Then a second apply graphic attached to a [1] message into [preset].
long winded but it saves the user having to locate the save file twice.
Will post patch soon its on my mac and not internet connected. (using laptop at moment)
Give yourself a pat on the back Chris for finding a logical solution to a complex problem. Eureeeeeeeeeeekaaaaaaaaaaaaaaaa.
Thanks Lee.
That's awesome to hear. Looking forward to the patch. Thanks for the pat on the back too. Up until now I was thinking this whole effort was a dead end. Glad to see people benefiting from it.
Hi Chris, I have found a different way of going about this, I have not implemented it yet but believe it should work really well. I have found lots of threads saying to use poly~ for effects that you wish to change as that way you do not get a break in the audio flow (as you do when using the replace bpatcher), Their is a help patch called dynamic poly~ in the poly~ help file. however I could not find a way to look in to a poly~ using bpatcher. Then it struck me last night laid in bed (as they usually do), For each effect I create I need to split it into two patches, lets say I want to create a simple delay using delay~. First I create a patch with a visual backgound and place all the nobs and faders in their in this case just a fader to control the delay time, I then send the fader to an outlet called deltime in the patch then I have an inlet attached to the input of the fader called bang and place an autopattr in their, thats that patch finished. Then I create another patch that has an inlet called deltime I attach this to a delay~'s second inlet and attach a inlet called audio in to the first inlet of the delay~, I then attach the first outlet of the delay~ to an outlet called audio out, I then place a loadbang into the this patch and attach it to an outlet called bang. Right once in the patch that I placed my bpatch in I load up the first patch into a bpatcher (the patch with fader/knobs) and have an offset message to switch between the different effect fader patchers (notice I havent used replace) now all you have loaded up are all the controls for whichever effects you include in your patch/standalone, then have a poly~ with the message patchername poly_(your patch name) attched. this will then load the patch with the actual audio flow and delay~ in without creating a gap in sound. attach the bpatcher to the poly~ so that the fader attaches to the deltime and attach the bang of the poly~ to the bang inlet in the bpatcher once the poly~ loads it will send its loadbang to the fader and the faders saved setting will be sent to the poly~. simples. hope this makes sense. will load up a patch once I get the chance. How you go about automating the bpatcher to load at the same time as the poly~ be simple enough. Just make sure all the control patchers you create for bpatcher are all in the same patch so you can use offset this way the autopattr will pick up the saved message from your pattrstorage. I only have one effect per bpatcher so no biggy for me only wanted to use bpatcher replace to save on cpu. thanks Lee.