bindMaster vs bindReference menu.toe (40.8 KB)
Lets see if this illustrates what I’m getting at. Given a scenario like this toe, where one might want to have a component dealing with sources that could change from session to session or machine to machine(in this case audio devices, but MIDI devices, Spout/NDI inputs etc are also relevant use cases), I would argue that having an independent tox for each thing (MIDI, Audio etc) and then a global settings component bound to these different parameters as a place to control it all might be desirable.
As illustrated here, if one makes the SETTINGS tox the bindMaster, the menuSource is given the reference to op(‘AUDIO’).par.Driver for example, and if those items were to change at the AUDIO tox level, the menu items are automatically propagated to their references. If the SETTINGS tox gets bindings as a reference, those menuSource references are not propagated, so if menu items were to change in the AUDIO tox, they would not be updated elsewhere in the project.
In this example, I would like my AUDIO tox to be a palette item I could drop into any project, keeping the logic self contained. To do this with bindMasters that propogate makes it dependant on my Settings chop, and I don’t think that should be the master, but I am forced to do it that way for now if i want my devices to update on other machines.
Ideally for either a bindMaster or bindReference, that menuSource reference gets pushed… I think that is what i am asking for. Does this make sense?