Share same bpatcher (with same parameters) between multiple tabs of global patcher
Greetings to C’74 readers.
Could someone give a tip about how to share the same bpatcher properly inside a (big) main patcher with multiple tabs?
That bpatcher will have different screen positions (by sending/using [script sendbox bpatcher_name x y] to [thispatcher] mechanism) on the tabs screens of the main patcher, but have to show always same (actual) state of its own parameters.
So If I made some parameter-adjustments through one parent-tab, I would like to see this on all the other tabs as well.
Please assist me.
Thank you in advance.
Alfredo
i think it is not possible to have multiple instances of a bpatcher being treated as a single one.
i had asked this question here: https://cycling74.com/forums/is-%22linking%22-bpatchers-possible but no one replied.
i think each instance of a bpatcher is an entirely separate entity during runtime, and unfortunately i haven't found a way to treat separate instances as "the same".
but i am not sure about this so please correct me if i'm wrong.
i think you have found some sort of solution yourself? to dynamically create a view of "the same" bpatcher when switching tabs?
Good day Mark,
thank you for your attention.
I was thinking that there is almost everything possible with this great tool...
What to do? Do we only ones who wish this feature?
I did tried to make a dummy bpatcher with the same amount of inlets/outlets and size and replace it via the script with the real one on another tab, which works, but it will only load the version of bpatcher that was saved initially, so without of its recent changes.
I was thinking to build an autosave trick into that bpatcher to save it after every editing of its settings, but MAX freezes for a few moments during of the saving, so its not an opting if you wish to work with audio or like.
Maybe I'm too unexperienced...
Hope someone can help us. Looking for it...
All the best,
Alfredo
Is there then a possibility to just move (not duplicatie) one bpatcher from one tab to another within one parent patcher?
That would be a compromis.
Please assist.
Thank you.
A
you would generally solve sharing data between instances of subpatches by the use of either send/receive or v/t b constructions at all points where data should be shared.
in fact it is not different from other forms of patches including parallel, sub, [p], [poly~] or [pfft~].
...but watch out for loops ;)
this is about what i was using... when i remember right... let my know if it works as i have not tested it now.
p.s. patch is fixed now :)
currently it still send data within the instance always twice to the aim. in most situations this is ok for a "parameter" (it wouldnt be for a "note on" type of event)
while you test and extend it, always use 3 bpatcher, if you only use 2 you might miss something.
"I was thinking to build an autosave trick into that bpatcher to save it after every editing of its settings"
never do something like this. tomorrow you need the same patcher in another app and then it has different settings.
Good day Roman,
Thank you for your valued input. The logic behind your idea is clear and with some tweaking I would be possible to "transpose" this to my situation, but need "some" time...
For my autosafe thought I've just used this formula: grab&drop the bpatcher (or file) and the address of the it will be filled automatically according to a new situation. It's not ideal and you are very right, its "dangerous" if there some changes on another machine will take place.
Thanks a lot again,
All the best,
Alfredo
saving a modified bpatcher is probably the easiest solution to synchronize all other instances.
but there is a whole list of contras, starting with the problem that if they contain audio signals, reloading them will interrupt the audio.
i would rather write my values in a .txt file and then somehow make all instances load that.
that' s great.
I mean, to autoload parameters-values on each tab-patcher. Would you advice to use the pattr system for this or coll?
Thanks for the thinking together.
Al the best,
A.
i am not using pattr myself, but it can ce easier to collect data in some situations.
the other solutions are indeed [coll] - or simply [preset],
for a bpatcher with some 15 numberboxes or sliders i find [preset] the most straightforward solution of all: make one connection for everything you want to include, store one or more prestes in preset object, write them to disk, open them somewhere else.
i usually have one fixed path for such application-specific prefs and presets files in my runtime, which i manually create in the finder (or distribute with the free runtime)
both preset and pattr set a dirty flag, you can get rid of that using...
[closebang]
"clean"
[thispatcher]
...but i would never promise for that to always work in [bpatcher] patches since max v6.
a (embedded) [coll] object would not require this.
note that each of these systems are not thread safe. parameters should not be changed by the user while the preset file is loaded from disk and such :)
Thank you Roman for this useful info again.
I did to test it and like the [preset] a lot, it works perfect with UI based objects, like [number] or [toggle] etc.
What I need in my case is to safe the states of many messages (boxes).
I've discovered that the [preset] does not „see” a [message] in the patch (even if I connect is to "include" to the most left outlet) so it did not safe the messages inside.
The solution I’ve used before is to safe the bpatch as already mentioned.
What would you suggest in this case?
Very interesting to know...
Thanks,
A.
if you need to store the "state" of a messagebox, dont use messageboxes - use coll right from the beginning.
but let me add that a messagebox can contain several symbols of the maximal symbol size, seperated by commas. if you want to include that in a "preset" it will become difficult.
one must make each symbol (or each list for that matter) one parameter.
actually coll would often be the best solution of all - if it had not that issue that you need to open its window to see its state. :)