@Oriah-Beats

I actually just did this the other day:
https://forum.hise.audio/topic/9656/orv-s-scriptnode-snex-journey/9?_=1752509228365

It is a bit crap, but it proves the concept.

Without trying to teach you to suck eggs, if you're not using some sort of version control, you really should. Grab yourself a copy of Fork and a Github account, and commit your project every time you make significant changes.

I've had previous versions of HISE do similar things, where scripts would disappear or be completely empty. Haven't had it happen for a while though. I'm trying to track the develop branch as closely as possible, so I get the most recent fixes and such things.

Anyway, here's the link to Fork:
https://git-fork.com/

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

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

@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 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 OK, apparently I can't show you a video, because now I also cannot get my demo snippet to work!! How strange.

This is so weird. I was sure it was working. Can't explain it, because I wasn't getting an error or anything previously, and my graph data WAS definitely updating, because in the video I sent to my client you can see the graph switching indexes - which is the whole goal of this.

I wonder if it was actually an older commit? I can't really remember now, But as recent as July 2nd, I was updating the Data array for a FloatingTile, using .parseAsJSON() and then setting the index to a value, and then performing a .toString() call on it, to shove the modified data back into the FloatingTile.

Anyway... trace() does work.... but this baffles me tbh. Maybe Chris can say if something changed. The only reason I posted in here was because he was asking for feedback.

local filter1Graph = Content.getComponent("ft_Filter1Graph"); // gets a component on screen
local filter1GraphData = filter1Graph.get("Data").parseAsJSON(); // parses the Data array for the component
filter1GraphData.Index = graphMap[filterType][0]; // this just returns an integer from an array, and sets the index property to that integer
filter1Graph.set("Data", filter1GraphData.toString()); // this shoves the Data back in as a string

In the full code, this was literally the code that was working until very recently.

@d-healey said in Roadmap to HISE 5:

@Orvillain said in Roadmap to HISE 5:

Was definitely working.

Can you show me a video?

Will do. But I'm very sure this was working at some point. I wrote the code and even sent a video to the client showing them this feature area working.

(updating graph index so that it looks at a different exposed filter graph from a custom filter node)

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

@d-healey Was definitely working.

@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 said in Roadmap to HISE 5:

@Orvillain said in Roadmap to HISE 5:

This code was working fine before upgrading to Hise 5

In which commit does it work?

May 30th. Hence my original question to Chris as to whether something changed in this HISE 5 round of updates.

@d-healey said in Broadcaster attachment design pattern:

The way I handle this kind of thing is to make a controller script. Then I just connect the knobs to the controller using processor/parameter ID.

Here's an example of an AHDSR controller that will work for any number of envelopes, you can add/remove envelopes and no change to the script is required, it's completely self contained.

It avoids that repetition you've ran into and can be reused in many projects.

Without bludgeoning you with loads of code, it is hard to explain. But I'm essentially dynamically creating parameter groups based on their names. Then I create a broadcaster for each group. Then I attach the broadcaster to each parameter based on the broadcaster type that is desired, then I am adding the listener callbacks to the broadcaster.

It is all very cool and modular. I just don't like this particular 3-engine manual duplicate approach, because if I want to move to 5 engines, then I need to do a bunch of manual work.

I was hoping for a design pattern where I could call the right number of addListener commands, against the right number of broadcaster or parameter groups. I can't just run a loop and use local variables, because local variables aren't allowed in inline functions in this manner.

@d-healey said in Broadcaster attachment design pattern:

Have you tested it in a compiled project?

Yes. Works fine!

@d-healey I don't think that is correct. This code was working fine before upgrading to Hise 5. toString() did exactly what you'd expect, it converted the JSON data object to a string.

Trace is fine, but I regard trace as a logging/debugging command, which is why I wasn't using it.

What I've got is working perfectly. I just think the code is a bit messy. It isn't just for envelopes, no. I'm doing the same pattern for a whole variety of areas in my synth.

But the one example is:

    inline function addEngineAmpEnvListeners()
    {
        SharedData.broadcasters["Engine1AHDSRControl"].addListener("string", "metadata", function(param, value)
        {
            BroadcasterCallbacks.controlLinkedAmpEnvParameter("Engine1", param, value);
        });

        SharedData.broadcasters["Engine2AHDSRControl"].addListener("string", "metadata", function(param, value)
        {
            BroadcasterCallbacks.controlLinkedAmpEnvParameter("Engine2", param, value);
        });

        SharedData.broadcasters["Engine3AHDSRControl"].addListener("string", "metadata", function(param, value)
        {
            BroadcasterCallbacks.controlLinkedAmpEnvParameter("Engine3", param, value);
        });
    }

And the callback I'm attaching to this is:

	inline function controlLinkedAmpEnvParameter(engineName, param, value)
	{
		local paramMap = {
			"Monophonic": 0,
			"Retrigger": 1,
			"Attack": 2,
			"AttackLevel": 3,
			"Hold": 4,
			"Decay": 5,
			"Sustain": 6,
			"Release": 7,
			"AttackCurve": 8,
			"DecayCurve": 9,
			"EcoMode": 10,
		};

		local engine = SharedData.engines[engineName];
		
		for (mode in SharedData.modeMap)
		{
			local modeData = engine["modes"][mode];

			local parts = param.getId().split("_");
			local paramName = parts[parts.length - 1];
			local target = modeData["ahdsrEnvObj"];
			target.setAttribute(paramMap[paramName], value);
		}
	}

It works splendidly. I just don't like that initial bit of code, because I'm repeating myself and specifying a different engine name each time.

@d-healey Yep that works. Just odd that the old call stopped working.

OK. Fixed that. I've gone for SharedData instead.

Existing question still outstanding - is there a pattern for running multiple addListener() calls without needing to rely on local variables ???

Oh, I thought the HISE namespace was called 'Global' - not 'Globals' ???? If I'm wrong, I will change the name to JamDoughnut after all!!!

@Christoph-Hart

Did anything change in the parseAsJSON stuff for a floating tile?

This is what I was doing prior to this update, and it worked:

local filter1Graph = Content.getComponent("ft_Filter1Graph");
							local filter1GraphData = filter1Graph.get("Data").parseAsJSON();
							Console.print(trace(filter1GraphData));
							filter1GraphData.Index = graphMap[filterType][0];
							filter1Graph.set("Data", filter1GraphData.toString());

But now the toString() call on filter1GraphData returns an unknown function error.

But when I print out the trace of filter1GraphData, I can definitely see data showing up.

Here's a simplified snippet:

HiseSnippet 1038.3oc0V0saiSDEdbalJhAVXQHDbmUtJAUEk+2VVgHaSZfrPSSIkEta0T6wIi53YL1i2tQqpfGEdA3cgmCth2fkyX6D6zVkMMqPh0WDkyOed9747MmYFGHsoggx.jg44y8oHiO.OYtPMq2LBSfF1GY7.7IjPEMvJw0Qy8IggTGjgwteq1gQwBn3m+4aNhvIBaZlKD5YRlM8GXdLUl2wc+dFmOf3POm4kK6VcGZKE8jbYDvmcw0P9D6KISoiH5z1Ai9NR3LjwWha2nocKmG4znQ6C6XS5POzk35VuoSqVcN3v5MOjz5fNzZsQF6crCSIClnHJZH7ROR5LexL4UhjE3YrP1Ebp1nNZBrxItQ8lw3NiWTbBQHiBiyJU6lTp9T7ILG1R+YkrONNfUFh7EMicVGkpeOnjQNJUHgRODOwNf4qxhn4y6iGJfNnKA5M4oRRtnc9SCbOIjgPU0ibIcP.XrDQ4N0psuE7SkGaZZBMnPk0KHAVCXbHi5VesUrfo5Tp5XWWpspbozPk.D4xmKIJlX54LNUiZwJB35I87kBv.flOqR2XIcU8IJBfckrzugxkzQJUopOIHj9jvmN4zQk0nSfTcnvg9R.XavUJ6pFtD19ou4pJ4DU.7dKWoxiciD1JlTXIEijJ5ohxULekYQyqMstYHW26Ll9KLPx4zf6LrV7GrNfkEQdWPC1G914QzkIBM6UUP6sYJH6jBdtDkhgBl5TeZp8.I2QqLz++15MTZGC92OMTWtzRvTePd9z.ESSGi9zW.a5SDjEw8ogWpj9w4l1lAEoJcGThDLe+Dw.F7Q3UZwnWlMkne24YFi5lRfjUCfE2b6yB84j4nKltXZRw8Z1r4q0PXJpWl2WCOq5sQp6eOdwzelFOE+JSKqRKKFCcJ8UVKU46qiEKv.u0hsfBIWd0OKCtLDFgQA+tDdH07ZzULGELBCa72FHzLJa5Lk1pigdt3s1NCCRjNQbhZ0oK54toA.AyJao0aaEgL077ykuGibps1QNaJEeHdLSYO6t43N2AGAoz+EbLcP8GhSlLkQvB3A+x1NUt1lOUtXx5+I3wR9b+YRAyNQ0DShhop05q4PUDZP.8WinB6EUq+35e6u5dV91KTlycJ5m28rHB+FU2iX9RNI3ssxeONibcxiOCu7ix5sQGWXyZRugwZarlV2Yd2gueANsoaoK1u6v6GfO6+Aj8GkQ5SeNg.2G.N7AOJxaBb3fMEHpPP4g5o16nOTLwtl1VSnITgSrg9jkzf001FoAquHHxiXGHetcxg858OuWrGfSh3K7VDt4MXaUGEeAf76Y8f6W9ba6UeU2BXisEXysEXqsEX6sEXmsE3i1VfG7lApu9+ShTRuDMLBcx3iStJgwwBBnFikyn+EvirgaQ

I swear this used to work!