I am big fan of the matrix object; it makes life a lot easier (thanks Emmanuel 
) But today I came across a problem, that looks strange to me.
I created a Matrix of panels. Each panel contains an encoder and two labels. The ids of the encoders a derived from an increasing number variable in the panel, as suggested by Emmanuel. The encoders send out midi commands to a VST and get correct feedback from the DAW, if I change the VST parameter. So in principle everything works as expected.
Since I want to use the same GUI for several plugins, I need to update the encoders in the matrix from the custom script. I do this by sending an /EDIT command the corresponding encoders. Now something strange happens: not only the addressed encoder gets updated, but also the ones after this one with higher numbers. E.g. receive('/EDIT', 'insCtrlr_'+idx, {"value":value}) ; with idx=3 updates all controllers from 3 to n. Is this intended, or am I doing something wrong?
Thanks for your help
hi, not sure if i can help, but maybe this is some kind of async going on here. I would suggest to do a console.log in the props of the clones (outputing their unique id). in the clones you did not forget about id’s (props.id). In my big project i use the same ids more times, but updating it each time on opening a panel (so the values are always corrrect). When i remember correct, edit is quite heavy, i use here receive in the custom module and the OSC{} Syntax in the widgets…(maybe because of that?)
Hi, could be. What makes me wonder is, only the widgets with higher numbers are updated.
There are so many ways to update values/properties and I still don’t know when to use which one: ‘/EDIT’, '/SET, osc messages, link IDs, ‘OSC{}’, @{}. Would be cool to have use cases for each one, in order get the differences.
But anyway. Did you put OSC{} in the widget’s value fields? In case I change the value field, the message of the widget is not triggered, is it?
Using /EDIT simply to update a widget’s value is inappropriate, you could simply send the value directly on the widget’s address (with preArgs if any). However, if you could upload a minimal session and step-by-step instructions to reproduce the issue it’ll take a closer look at it.
Hi, thanks for your offer. The widgets address is a midi address, no osc address. While I’m thinking, it likely makes no difference, since in the background you are probably converting midi to osc and vice versa anyway. I will try
It will be hard to create a minimal session, since it’s a interaction with Cubase, sending data back and forth. The machanism is as follows: When I change a VST parameter in Cubase, a midi message is send to OSC. The message is parsed in the custom script, and the name of corresponding widget in the matrix is generated, which in turn is sent to the widget: receive('/EDIT', 'insCtrlr_'+idx, {"value":value}) ;. The console.log shows the name is generated correctly and the widget (and those with higher idx numbers) get updated. The widgets with lower numbers are not affected.
Hm, still thinking about sending midi to the widgets, since the address is formed of input and output port. How can I address the input port? If I use ‘send’, the midi message is sent to Cubase (output port). What happens, if I use ‘receive’ instead? Will it be sent to the input port? Confused…
You can use receive which sends the message to the clients / widgets directly. You’ll need to match the address and preArgs (https://openstagecontrol.ammd.net/docs/widgets/general-mechanics/#receiving-messages).
On the initial issue: can you upload your session file, or just one that contains that matrix widget ?
Something must have been totally messed up yesterday. All of a sudden, the knobs generated a midi message on the OSC midi input when I passed a value of ‘63’ , creating a feedback loop, preventing me from changing the value of the knobs (they always popped back to 63 e.g. half way through). The message was not sent from Cubase and was probably somehow internally generated. After a reboot everything worked fine, also the /EDIT problem. Hopefully the problem will not come back. Thanks so far