MenuSource bindMaster vs bindReference stable 28110

Wishlist and RFEs
#1

attn: @Ivan

I’m running into some frustrations with the difference between binding a menu as a master vs reference. When I bind it as a master, the menuSource behaves as I’d expect, and is set to op(bindTarget).par.Menuitems, and when the menu items are updated that information is propagated to where it needs to go. However, when binding as a reference to another menu, the information is pushed once when the menu is created, but the updates don’t push as one might expect. Is this necessary by design, or would it be possible to get consistent behavior for menus here? Thanks

#2

We’ve been discussing this a bit internally. Are you talking about Comp Editor behavior here or binding in general? Maybe you could post an example tox, and/or step-by-step instructions illustrating this? Just want to be sure I understand what you’re struggling with.

#3

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?

#4

I get where you’re going but not totally sure I grok. You want to be sure that SETTINGSparReference gets the menu options properly? In this file, I just filled in the menuSource on the Device and Driver pars on that op: bindMaster vs bindReference menu.1.toe (4.3 KB)

Does that file have the functionality you’re looking for? Or are you hoping that will be more automated?

It’s a tricky thing to automate setting the menuSource, because design-wise they don’t actually have to match. So it’s possible to set it up that way (like in the example) but it needs to be explicitly done.

#5

totally get that i can manually do the menuSource thing; was just hoping for the same consistency from the bindReference as the bindMaster. I ran into this through some dynamic UI building, and i know Darien is doing a similar thing that requires a workaround for the TDMorph UI, requiring menus to be treated differently then all the other par types because this menuSource isn’t automated on bindReferences. I suppose there is a pythonic way to do it through a second call, but i figure if the functionality is there already for bindMaster, maybe its not too tricky to build that automation in for bindReferences

#6

Are we just talking about component editor behavior? I believe that’s the only situation that the master might work different from the reference. If you bind parameters programmatically, you always have to fill in the menuSource yourself. So this second step is just Par.menuSource = “”

The reason menus don’t match automatically all the time is that theoretically you might want to limit the choices in some places along the way. This was certainly a debate though… maybe we need to take another look.

#7

Yes, that’s the use case, custom parameters in the component editor. Because menus and stringMenus are the only parType that requires a menuSource, and because this is done automatically if its a bindReference vs bindMaster, the bindMaster is the only use case in which one would have to pass this information. I get that its possible to run checks for this in the for loop, and if it is one of these parTypes, and if it is a bindMaster, to pass that menuSource, but since this is already being done for the references, it would be nice if that could happen automagically… one could always manually change it later, or set it as another step if that is the desired behavior, I would just argue that it should be the default, just like a it is for bindReferences or for normal python references when creating the parameter. I understand that this is a rather edgy case, and probably not super high on the priority list, but if its enough to reopen that debate and make the behavior consistent, I’d be appreciative

#8

Yeah I can make that smarter. I agree it’s probably the desired behavior in most cases. There are a number of permutations here, so just to make sure I hit yours, one more question about your specific use case: In the file you sent, which parameter would you be dragging into the Comp Editor when setting up your custom parameter? I’m guessing it’s the one on AUDIO component? Like you’d be making a custom component that references the AUDIO component and you’d just drag the one from AUDIO itself?

#9

Yes, in this particular example, AUDIO would be a comp I could drag into my project form palette, where the audiodevin has been bound to the parent as master. The SETTINGS component would be made later, and when customized, parameters from elsewhere in the network would be dragged there and bound as references, so that this op.AUDIO is still the authority in terms of where the logic is driven from. Dragging from AUDIO to SETTINGS and binding as reference would also pass the menuSource as it already does when binding it as master

#10

Okay I’m going to make the menuSource setting automatic in Comp Editor when you drag a menu. I think that’s the most common desire, and it’s quite visible when you create the parameter. Coming in next 40k release.

Thanks for feedback!

1 Like
#11

:pray: :pray: :pray: Thanks Ivan! Mucho gracias!