Callbacks and Broadcasters Executing on Init; Global Variable Space as a File

[Lindon]

@d-healey said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

The same way I'd pass information between my UI and an effect - or any other HISE module. Either using processor/parameter ID or setAttribute.

The problem with this is that this is UI downwards only, so there is no way to pass a value to the peers of a module, or back up the chain - only downwards...

[d.healey]

@Lindon Each of my modules works independently, the only time I pass information is when something the user changes on the GUI needs to change something in the module.

I have a round robin module, I have a legato module, I have a mixer module, etc none of these need to communicate with each other, but the GUI might need to communicate with them.

The only exception I can think of is things like the arpeggiator where I might want to see something it generates appear on the UI, for this I'd use a slider pack or table and link them via processor ID.

Can you give me a scenario where you want intercommunication between modules and there isn't another way of achieving your goal by making the modules independent?

[Lindon]

@d-healey said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

Can you give me a scenario where you want intercommunication between modules and there isn't another way of achieving your goal by making the modules independent?

Sure.
I have a system with a global level arppegiator, I want the 4 voices to listen for the arp note arriving(easy enough to do with a script processor) and then for one of the voices, the "master voice", to make a decision about if its going to play the note...and to then tell the other 3 voices its decision....so they can join in - or not.

[d.healey]

@Lindon said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

I want the 4 voices

What do you mean by voice?

[Lindon]

@d-healey sampler

[d.healey]

@Lindon Ah I see the issue, because the encapsulated MIDI processors can't see each other. Could you put your master controller outside of the samplers' MIDI processor chain?

Can you give me an example of what circumstances the master will decide not to play a note?

[Lindon]

@d-healey said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

@Lindon Ah I see the issue, because the encapsulated MIDI processors can't see each other. Could you put your master controller outside of the samplers' MIDI processor chain?

Can you give me an example of what circumstances the master will decide not to play a note?

Im sure I could, but you have the point - its occurred more than once in more than one instrument for me - essentially extending the playback systems is difficult in HISE given this limitation of encapsulated MIDI processors not being able to communicate with any modules not below them in the "chain of command"

So you are left with this "poor encapsulation" approach of designing a master processor....which is just moving globals into another spot...

[d.healey]

@Lindon said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

Im sure I could,

Without an example I'm just guessing here so this may be totally wrong. Let's say the master decides it won't play a note if it's MIDI number 60. And it needs to communicate this to the other processors.

In this simple example I would say why not make all of the other processors independent so they all ignore note 60 without needing the master to tell them. Essentially they all share the same script as the master and you only have one script to maintain.

[Lindon]

@d-healey said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

@Lindon said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

Im sure I could,

Without an example I'm just guessing here so this may be totally wrong. Let's say the master decides it won't play a note if it's MIDI number 60. And it needs to communicate this to the other processors.

In this simple example I would say why not make all of the other processors independent so they all ignore note 60 without needing the master to tell them. Essentially they all share the same script as the master and you only have one script to maintain.

okay - well how about we stop trying to fix the specific - because I just made it up - and try to focus on the generic problem?

[d.healey]

@Lindon said in Callbacks and Broadcasters Executing on Init; Global Variable Space as a File:

on the generic problem?

I don't see a generic problem as such, I see a structural issue with your project - but it could be that that is the only way to structure your project and then there would be a generic problem. It's difficult to say without real examples to work with.

[clevername27]

@d-healey @Lindon

Is that always the case? I vaguely remember documenting a situation where threads were executing (twice) before onInit. Something to do with default presets

I haven't used the default preset thing so that might change things but the usual behaviour is as I described.

Wisely said; here's the thread: https://forum.hise.audio/topic/10723/preset-component-callbacks-triggering-twice-on-startup/11?_=1742336098253

Is that always the case about Callbacks?

I will investigate - it will take me a couple weeks, but I will get back to you.

Do you mean manually inserting a conditional check
Yes, in every place you don't want it to execute automatically.

I appreciate your thoughts. For me, at least, that solution isn't tenable. I have far too many callbacks, and it has emerged, on my end, that I am unable to always tell if a callback is being called at startup—or even what means, when you get into the various preset handling systems. But overall (and this is a @Christoph-Hart thing, not you), to me it is an illogical and limiting design choice. I get why it's there, and I'm free to write my own HISE. I just think it's wrong, much like with the broadcasters.

How do you pass data between (for example) UI and real-time threads.
The same way I'd pass information between my UI and an effect - or any other HISE module. Either using processor/parameter ID or setAttribute.

I thought about this, a lot. Because generally, I agree with you (and I teach my students as such) that global variables are to be eschewed (and because your code is so elegant). But there are legitimate usage cases for them. And more to the point—if the language says it supports global variables, then it should do that. At one point, @Christoph-Hart improved the handling of globals by introducing the Global object…but…and please let me know if I have this wrong…didn't fix them so they work properly.

Out-of-order execution during startup.

I have looked high and low for the screen-capture movies I made, but I don't think I was able to upload them because they were over 10MB, so I deleted them. I do remember that another user appeared to be having the same issue. I simply had to spend a couple weeks completely refactoring my code to get around that issue.

Anyway, thank you, as always, for giving thought to my questions.