How to debug control not linking in exported plugin?

[Simon]

@d-healey It behaved the same when it was in a constant. Is there another way besides using a global variable or linking controls together with a callback?

[d.healey]

@Simon said in How to debug control not linking in exported plugin?:

Is there another way

It depends on what the goal is, but I think it's a structural issue. Without knowing more about your project it's hard to give specific advice. Can you send me your project or tell me more about what this element's purpose is?

[Simon]

It's for keyswitching. In the realtime script, on note, if a note is in the KS range, it updates a knob. That knob is linked to a knob in the deferred UI script, so it can update the key colors on screen. That's it really. The keyswitching is working, because I can hear the articulation change, it's just the linking part that doesn't work.

It's tricky to debug as it only happens in a compiled vst or standalone. I'll probably try Christoph's logger next: https://forum.hise.audio//post/26752

[d.healey]

@Simon I understand now. This is how you do it.

Your real time script does the keyswitching (changing articulation). In your UI you have another script that also picks up the keyswitches and updates the UI. The two scripts don't need to communicate.

[d.healey]

@Simon Here's a snippet that demonstrates it, the keyswitches are 24 and 25.

HiseSnippet 1662.3oc6ZstaSbDEd1jroXCkBHpfetD0eroDErcBIDQQDxMHBLwJN.UBgPi2c13Qd2YVsyrowsBo9pzmj1Gg9HzGAdCZOydwdWGiwwwDHzDEEk4Lma64Ly46acRs.tEQH3AHsh601mfztjd81LYy0ahoLz1afztrdUrPRBLhEsVaerPPrQZZS9Xk.sBSgh958ObMrKlYQ5JBgdImZQdF0iJ6Js1pOk55tE1lrG0Ki1Kt51Vb15bWdHjOSpWB4isZg2m7brRsIzQOAKZhz9Q8R2cIBY4EbrswKrf8RKszJ2akEWoL1ozh3FkWZkEqr3xUt2xNHso2zlJ4A0kXIQ.NcMtc65M4+BKN.ujJnMbIpEkQ0gHGKFsdSpqcszhi.gzzq0sTMYbo555Uo1zNx6VxtRzFFcsHaQSahAkRkOFojVlTZp3T5p50sBn9xt6nxmKpuMC5fNXn2jMUh0EMwenouNGzfIm2C2hrU.rniElKUpzbFvOl89EKFc1XdahCIXcrqaCn+HLkAgD0lPySHMZILdfwqqr3bFUt6a5Jk03QARpUnKVR4LPkzHtOQtN2ymyfElyzidyn7qSHyJxHN64bIYGl4rE+shEb4VXWCkqpBOpvwDkqTJ77PuFj.SvzBEKPcLLaIlGxBIzdDlrYmsXAv5B8Do4ED4KwtgDk1TlM4vcbTJCN4cEeWQidSBGm3rnm8TOUAbWWU76y1pC7ACxPSVTxOmwApboihPCN+oloGtSMVwE4LJxYaynxc7IIq2h6ZqNMn98idFCkzkTm1RxPPUYzYsKmbVqtK0lDfn1pie8TUQQOFYmQfdw1afk3TGB9FhmOArQ8XosA4.XfQ7g4B5aPDsjb+HcSNhfz9liQ3OrSn+8Vq1tyh+xcUOpssKoFWPiTrSF9OODF14Wm9qPHz0KOeIjjbnTEtbNFcz6dvsdtsZ+7iBTCIS1PYX16ep6XLHAZms.cLlOTZfyGF1T7p50nRql8OGmnO4Hz69TjiISU+V8McbHVxtI3T5a8yi5HzgO7W3Cf+conYivJRP4wA5m+Pi9oM43B7Z5OCfWkFSfWeuNNyEOHOY6SB5KLl+j5CBBxKDPzh1QIygGXXRsMnLiXPM.7Xa6mQE.Hjp.TUo8LJvhX6l2OTzzrip4Jdfeh.JJdm6bqdQ59n3eXa6mx3MLmIGt2bF.nqBxsOvT6pJAlv9kgu6uJIypSwnM4rdTJQAE7Jk4BGtyhE0ecMsRmAmEcxJpgjUcy3MuOfaEUP1JwwhiDo9XaDxajiiaPPgpz8MnF+TR6adWBaeYSPzsuMzaRZNul9F0S8ijx.ZCPhYWwz8Y7.xZgRImMG3na8.i3X.42mFhEoFEG4MOPwqIkhzwg1wQTMtbYGE+2UnvWfrRzGWrRNwLQ5AtNgFhtllZT6IlBRwgMtGphoJjsS+EgrspfLst5RO5CwB48+YWVHcQXDgNNzCidSHGpqm.Ns6usGbVCocM8WHHF.wbbnqzPzBFlC20ZQr2iGo+47U9ZiuxMhC+E0eE9.RDtTBboZML7zy3wDfyhp1MHdK+83m2xNVRHE1K.yD9bAobVOWm3Q2CtEIxIsGKpzWKxIcChLjk20whxokpTrETJxn2EVMUXkrBqgY4bFrNmmpROL66HrICCMr5D3I2dGgETXT04rWKpE5JHuhZKaVNqgcEWIq3mfCrgdnUtCs8P+apga3Z96uYz+rGuvISOh2gPVBi7NqyexdvDlOFezJY.al3CA1DSoHYneVVF84cdGBe7c5vn85xPqVJfbQuNAcVXBdtlWgzbrN0y2krI6.hKfxFkiWCfUiPpRkluOVky39M4LZt6C6R.7t8Uj+yj688AB3ABjd6J45qtKwkfEYpm+vpOCnhhCf5DYDqEG+Oct91utodb5ZnFqZb1E4cx+2f7N3ae.RwW1cwanCHVULhZkFed5k6xCkT19UwvMZEEY3EqpCzGrHpWumQbUuJg1Dp4vwqKkxdtNgYGs3eguR1rbJud0lkS2bDoJU4bpRcDdk9QU5lmSU5rIUoJmAnJk3tyoJM.pRUNmpzImpzTCWe6i7GG6zi1zXOeGcJTmpktSNcpS0zcrQsZ7j0mFzr9ZIFdXq.9ashQeTCktPjDn1xh9uOofdU0ZixGEtwCfXeqkUdWcDCqLpFtvnZ3hipg2cTMboQ0vkGUCu2G2PECnGEJ4dI+k6QUqsYzm+ulVL2znqkn+CfV1fAi

[aaronventure]

@d-healey yup this is the way. Put the key switching stuff into functions and into an external script, then include it in both the interface and real-time processors, so you only have to maintain one version of it.

[Simon]

Despite separating the two scripts as much as possible, I've run into the need to get an integer from the realtime audio script into the deferred interface script.

Trying to use a global here causes a race condition where sometimes the value gets updated before, sometimes after.

This time I created a panel in the interface script, and set its value with Interface.SetAttribute(Interface.storagePanel,value)

It works in an exported plugin, but I'm not sure why!

[d.healey]

@Simon said in How to debug control not linking in exported plugin?:

Despite separating the two scripts as much as possible, I've run into the need to get an integer from the realtime audio script into the deferred interface script.

If you want I can take a look at your project and see if I can suggest an alternative approach.

[Simon]

@d-healey I appreciate it, but I already know the alternate approach is re-implementing a bunch of legato logic in both scripts. I understand that's the "correct" way to do it, but if the panel method works I just can't justify the additional code and time spent.

Is there a reason this separation is so insisted upon? The integer in question must be kept track of in the audio thread anyway. Is the performance overhead from setting panel data really higher than running the legato logic twice? Maybe there's a potential for catastrophic failure I'm not seeing?

[d.healey]

@Simon said in How to debug control not linking in exported plugin?:

Is there a reason this separation is so insisted upon?

I think it's just good practice in general with most programming systems to modularize and separate functionality from form. This is why a lot of programs are separated into backend components and frontend components, and you can have multiple GUIs for the same programs because the backend logic doesn't have to change.

[aaronventure]

I'll suggest something (David, cover your eye) :

Create a broadcaster in your interface script for the sole purpose of writing these variables, but create it into a global.

Add the functions (reading the global variable from your realtime script), then just trigger the broadcaster in your realtime script.

That way you bypass midi execution order.

[Lindon]

@aaronventure said in How to debug control not linking in exported plugin?:

I'll suggest something (David, cover your eye) :

thats just cruel..... funny, but cruel.

[d.healey]

@aaronventure said in How to debug control not linking in exported plugin?:

Create a broadcaster in your interface script for the sole purpose of writing these variables, but create it into a global.

I thought that might be a good use for globals too but it doesn't work - https://forum.hise.audio/topic/9746/broadcasters-best-practices/42?_=1736095809561

@Christoph-Hart said in Broadcasters best practices:

yes, don‘t. The global variable system breaks apart as soon as you are calling functions from other script processors as it was designed for data sharing across modules. Treat the option that you can slap a broadcaster to a global variable and react to events from another module as an easter egg functionality but I absolutely cannot guarantee that it will work 100%.

There is an attachToModuleParameter broadcaster which might do it, but it also doesn't seem to work at the moment - this one's a bug though whereas a global broadcaster is not intended to work.

[aaronventure]

@d-healey Dammit, I felt so smart for a second there. Totally forgot about that thread, I don't recall reading Chris' reply there so that's good to know, thanks. I should probably check whether I actually did that anywhere...

[Simon]

The root cause of this was actually this bug: https://forum.hise.audio/topic/12055/control-callback-does-not-fire-in-non-ui-script-when-value-is-updated-from-onnote?_=1740472879585