@Christoph-Hart Looks like Jatin has made some progress with this:
https://github.com/jatinchowdhury18/RTNeural/issues/143#issuecomment-2472915024

So does this bring us closer to being able to load NAM models into RTNeural inside Hise???

Damn! Missed it!!

@d-healey I'd do this in the raw sample content, personally. You could easily script something in Lua inside Reaper to do this.

@aaronventure Nice one cheers!!

@aaronventure Is there a good beginner tutorial on how to use Faust within HISE?

@clevername27 Are you using broadcasters?? Those all seem to fire off once on init as they get connected.

@Christoph-Hart said in New feature: Release Start:

Waveshaper OF DEATH

:face_with_tears_of_joy:

@griffinboy I'd love to get a look at your process there!

This looks great @griffinboy thanks!

I was literally pondering how I'd prototype something in Python, and then port it over to HISE. I reckon super basic Python prototype > c++ nodes > ScriptNode network using said nodes.

@aaronventure No idea tbh!!

@aaronventure

Yeah nice one, I get it now. It worked inside HISE but not in the plugin because the scope of the broadcasters was wrong. Won't make that mistake again!

I've genuinely been hitting my head against this for 4 weeks. :pouting_face:

FOR GOD SAKE!

Yes, that was it.

I am a huge idiot and should be thrown in the bin like Kurt Russell in the movie 'Soldier' - which I might watch tonight rather than devving, coz clearly I suck monkey nuts at it!!!

Thanks @aaronventure for the input, and the nugget that made me spot my error!

Wait... I think I might know what it is.... and I think I'm being dumb....

	inline function setupMuteSoloListeners()
	{
		local mute_bc = Engine.createBroadcaster({
		id: "Mute Listener",
		args: ["component", "value"],
		});
	
		local solo_bc = Engine.createBroadcaster({
			id: "Solo Listener",
			args: ["component", "value"],
		});
		local micsContainer = g_moduleMap["mixdownBusContainer"]["micsContainer"];
		
		local mutes = Content.getAllComponents("_mute");
		local solos = Content.getAllComponents("_solo");
		
		mute_bc.attachToComponentValue(mutes, "");
		solo_bc.attachToComponentValue(solos, "");
		
		mute_bc.addListener(micsContainer['routing_matrix'], "Mute", muteChannel);
		solo_bc.addListener(micsContainer['routing_matrix'], "Solo", soloChannel);
	}

That sets up my mute and solo broadcaster... but if the reference to the actual broadcaster is setup as local within an inline function..... will that break it inside a plugin???

@aaronventure

Right, so this is my entire interface script:

Content.makeFrontInterface(1920, 1080);

include("ModuleMap.js");
include("defaultRoutingMap.js");

// Only run this when I want to rebuild the Module Tree
//include("TreeBuilder.js");
//TreeBuilder.buildDrumPluginModuleTree();

include("ModuleSetup.js");
ModuleSetup.setupModuleTree();

include("Colours.js");
include("Paths.js");
include("ConversionUtils.js");
include("channel_dicts.js");
include("UISetup.js");

UISetup.ui_createMicrophoneElements();
include("SetupBroadcasters.js");

SetupBroadcasters.setupSampleMapLoadListeners();
SetupBroadcasters.setupMuteSoloListeners();
SetupBroadcasters.setupPanAndLevelListeners();

Everything that is happening is predicated on the existence of the ModuleMap - which is my overall global data handler. Here's a snippet of that:

const g_moduleMap = {
    "mixdownBusContainer": {
        "index": 0,
        "name": "mixdownBusses",
		"channel_count": 52,
        "object": null,
        "routing_matrix": null,
        "gain_stages": {blahblahblah},
		},
etc etc etc etc
etc etc
etc
};

The only thing that happens prior to including the ModuleMap.js file, is creating the front interface. Everything that happens afterwards, is in the correct order.

The broadcasters are setup only when all of my global variables and my data is in place.

It sure is a puzzler!!

I tried moving all of the include statements to a dedicated midi processor, before the interface processor, and that just broke everything and my broadcasters stopped working even in Hise.

@aaronventure said in Broadcasters working inside HISE but not inside compiled plugin:

Make sure that any global declarations are among the very first things you do in the very first MIDI processor in your project. I have a Globals processor above my Interface processor which does just that.

Maybe I'm being a n00b, but how come I can't just declare that stuff in the interface script?? I don't believe I'm trying to do anything with the global variables before declaring them, but I could be wrong.

@Christoph-Hart said in Broadcasters working inside HISE but not inside compiled plugin:

Oh and loadFromJSON with a relative path is weird, not sure if that will work. Include it as script and assign it to the variable in the file.

Yes I've just done this, as it was my first hunch too. But it made no difference. Seems like good practice to use dedicated explicit scripts anyway, rather than loadFromJSON.

@aaronventure I believe I am.

Here's the relevant bit of my Interface startup code:

Content.makeFrontInterface(1920, 1080);

const g_moduleMap = Engine.loadFromJSON("../Scripts/ModuleMap.json");
const g_defaultRoutingMap = Engine.loadFromJSON("../Scripts/default_channel_data.json");

// Only include these lines when I want to rebuild the Module Tree
//include("TreeBuilder.js");
//TreeBuilder.buildDrumPluginModuleTree();

include("ModuleSetup.js");
ModuleSetup.setupModuleTree();

include("Colours.js");
include("Paths.js");
include("ConversionUtils.js");
include("channel_dicts.js");
include("UISetup.js");

UISetup.ui_createMicrophoneElements();
include("SetupBroadcasters.js");

SetupBroadcasters.setupSampleMapLoadListeners();
SetupBroadcasters.setupMuteSoloListeners();
SetupBroadcasters.setupPanAndLevelListeners();

The only thing that I can think is that somehow the reference to g_moduleMap and g_defaultRoutingMap are not being setup correctly when inside the plugin.

Should I turn these into .js files with explicit declarations of the JSON tree's I want to use as my global data handlers???

I'm at a loss here. My broadcasters are working fine inside HISE, but not inside my compiled plugin. I don't really know how to debug this.

Are there any gotchas to watch out for?

I have a set of mute and solo buttons. I also have a set of volume and pan faders. These are all working inside HISE without any problem. But inside the compiled VST3 plugin nothing works. I do hear my sampler audio, so I know the plugin is working on some level.

This is a big project. Not really sure what code to provide to help debug!

@aaronventure Yeah the builder builds the module tree, and you get that in the plugin once it is exported. But any data you derive from the builder won't get initialised correctly, which is to be expected. I'd just overlooked it.

For example let's say I do:

const builder = Synth.createBuilder()
const moduleReferences = {};
inline function buildTree()
{
     local index = builder.create(builder.Modulators.AHDSR,    // the module type
     	               "GainAHDSR",        // the ID 
     	               sampler,                     // the parent module
     	               builder.ChainIndexes.Gain);  // the slot type

     moduleReferences[index] = Synth.getEffect("GainAHDSR");
}

A fairly contrived example... but the code above should work and inside HISE when developing, it will make the AHDSR, return the module tree index for it, and then store an object reference for it in the top level moduleReferences dictionary.

But in the plugin, since the create() method cannot run, we don't get an index, which means the moduleReferences insertion doesn't resolve, which means anything relying on that data further downstream, will not work properly.

In my scenario, it was all my broadcasters that broke. The samplers worked and played back, but the broadcasters I had setup to control module parameters from UI controls, were completely broken. Because the reference dictionary I had setup for their targets, were completely empty. They were completely empty because I was initialising them within my builder calls.

So.... I did know that compiled plugins don't have access to the builder... but I didn't really absorb it.

I wrote a function that would create some containers, then store the index for the container in a global array.

It worked inside Hise when developing, but it didn't work inside the compiled plugin. Why? Because the builder.create call I was using doesn't run, so I don't get an index, so the global array is empty.

So, if you use the builder at all... make sure to separate out your concerns. Only use the builder for constructing the module tree, and don't expect to store the index variable from a builder.create() call, and use it elsewhere across your plugin.

Instead, write an additional function that performs whatever Synth.get call you need, to get a reference to the created module, once you've created everything.

I spent a chunk of today refactoring my code into two namespaces - TreeBuilder, and TreeConfigurator. The first just creates the modules I need according to a JSON object created earlier. The TreeConfigurator does all the hard work by getting references to modules, objects, and parameters, and storing them for future access.

The More You Know.

@bendurso said in Is it possible to bundle all samples in the plugin?:

You can disable the Install Samples dialog, and enable the "Locate Samples" dialog. Users only need to select the samples folder and that's it.

Reply

How do you do this out of interest?