Broadcaster attachment design pattern

[d.healey]

@Orvillain Engine1AHDSRControl These are referring to AHDSR envelopes?

[Orvillain]

@d-healey said in Broadcaster attachment design pattern:

@Orvillain Engine1AHDSRControl These are referring to AHDSR envelopes?

No, it refers to a broadcaster ID created in a previous step.

I'm not going to post everything I'm doing, but imagine it more like this:

    inline function addEngineLinkedFeatureListeners()
    {
        SharedData.broadcasters["ENGINE-NAME-HERE-FEATUREHERE"].addListener("string", "metadata", function(param, value)
        {
            BroadcasterCallbacks.controlLinkedFEATUREParameter(ENGINE-NAME-HERE, param, value);
        });
    }

I want to do the above, where the engine name or identifier increments. But I can't do that with a for loop, because it complains about it not liking local variables.

Engine1AHDSRControl is a broadcaster id. and depending on the number of engines, I automatically create these. So for 3 engines I get:

Engine1AHDSRControl
Engine2AHDSRControl
Engine3AHDSRControl

And if I change the number of engines, my code will dynamically create the right amount of parameters, the right amount of broadcasters, and the right amount of parameter/component groups, and then it will attach the correct broadcaster to the correct component group.

Next step is to add the listener to the broadcaster, in a dynamic way.

[d.healey]

@Orvillain This error?

Interface:! Engine3AHDSRControl: BroadcastersBuilder.js (291): Illegal iterator target

The error is being triggered only for Engine3 so that implies the for loop in general is fine, but there is a more specific issue.

[Orvillain]

@d-healey Yeah, there's some underlying closure thing going on I think.

[d.healey]

@Orvillain

for (engine in engines)
{
    local capturedEngine = engine;

    Globals.broadcasters[engine + "AHDSRControl"].addListener("string", "metadata", function(param, value)
    {
        BroadcasterCallbacks.controlLinkedAmpEnvParameter(capturedEngine, param, value);
    });
}

Oh I just realised the issue - the function within your loop doesn't have access to local variables outside of the function. So you'll need to find another structure.

One workaround is to use a lambda variable, I try to avoid this because I find their use usually indicates a structural issue. But it's a quick and dirty fix.

function[capturedEngine](param, value)

Another suggestion is instead of using an array of strings and a for in loop. Just use a for loop that counts from 0 to the number of engines you have. Then you can just declare a NUM_ENGINES constant at the top of your script and use it whenever you need to know the number of engine you have.

[Orvillain]

@d-healey said in Broadcaster attachment design pattern:

Another suggestion is instead of using an array of strings and a for in loop. Just use a for loop that counts from 0 to the number of engines you have. Then you can just declare a NUM_ENGINES constant at the top of your script and use it whenever you need to know the number of engine you have.

If I try that, for example (different feature area this time):

		for (i = 1; i < SharedData.engines.length; i++)
        {
            SharedData.broadcasters["Engine" + i + "ModeControl"].addListener("string", "metadata", function(index)
		{
			BroadcasterCallbacks.setActiveModeForSlot("Engine" + i, index);
		});
        }

Then I get:

Interface:! BroadcastersBuilder.js (260): Can't reference local variables in nested function body {{SW50ZXJmYWNlfEJyb2FkY2FzdGVyc0J1aWxkZXIuanN8ODQ3MHwyNjB8NTc=}}

[d.healey]

@Orvillain The error is basically saying what I said.

You can't access a local variable declared outside of the function.

[Orvillain]

@d-healey Indeed, indeed.

		for (engine in SharedData.engines)
        {
            local capturedEngine = engine;
            SharedData.broadcasters[capturedEngine + "ModeControl"].addListener("string", "metadata", function[capturedEngine](index)
		{
			BroadcasterCallbacks.setActiveModeForSlot(capturedEngine, index);
		});
        }

This did seem to work however.

[d.healey]

@Orvillain Yep that will do it, it's not the most elegant solution but that's what it's designed for.

[Orvillain]

@d-healey More elegant than what I have right now I am thinking!

[d.healey]

@Orvillain Yep it will certainly help reduce that repetition

[Orvillain]

@d-healey Yeah, I think I can essentially boil down 11 functions down to 3 functions with this. Pretty cool, cheers!