@Straticah what were the exact issues with the mod matrix?

@Straticah it might take another week or two. The wavetable rehaul is almost done, then I‘ll work on the matrix.

@HISEnberg I‘ve been doing some work on the global envelopes recently (there were a few other glitches). It‘s not pushed yet because it‘s part of the bigger update to the modulation matrix that‘s in the works but maybe that will solve your issue too.

No, anything you write into a script can be readable when reverse-engineering the binary.

If you use the script unlocker you get the same level of security as a standard C++ copy protection though.

Funny, I'm currently sitting on the wavetable synth, but hard sync is not possible without nasty artifacts - the reason is that I'm creating mip maps with perfectly band-limited wavetables for each octave but this goes out the window if you start hard-syncing the wavetables.

You'll get a bunch of other nice things though soon...

If I'm using the global cable code creator with your Ids I get:

// Use this enum to refer to the cables, eg. this->setGlobalCableValue<GlobalCables::dataCable>(0.4)
enum class GlobalCables
{
	dataCable = 0,
	otherDataCable = 1
};
// Subclass your node from this
using cable_manager_t = routing::global_cable_cpp_manager<SN_GLOBAL_CABLE(-389806413),
                                                          SN_GLOBAL_CABLE(165255555)>;

Have you created the boilerplate code with the correct IDs? The hashes look suspiciously similar.

The input parameter is the shader file name (without the .glsl extension and the file must be inside the Scripts folder of your project (it will be embedded like any other script file when you export the project).

HISE | Scripting | ScriptShader

A OpenGL shader object that can be rendered on a ScriptPanel

(docs.hise.dev)

// That's the image folder...
const var glslPath = "{PROJECT_FOLDER}Images/bunny.glsl";

The about tab in HISE shows the most important preprocessor definitions as well as their current value (even respecting the new dynamic preprocessor functionality that allows you to change them on a per project basis without recompiling HISE).

I can add more definitions there if you think something is missing, but that place should be the goto location for checking this.

@pcs800 please don‘t post AI code here - it poisons the code quality in the forum.

You can obviously use AI for yourself but typing something into ChatGPT and then paste in here here for DaveGPT to correct it is super lazy.

@griffinboy yeah that was also my initial assessment.

@griffinboy said in Global Cables Don't Work when compiled:

I started my own fork of juce to try and get around graphics limitations in Hise (using visage)

Have you found a way to embed a Visage component into a JUCE UI? That's the new UI framework from the Vital guy, right? If that's possible then we could talk about a "HighPerformencePanel" component powered by this framework...

I decided they aren't for anything fast anyway due to the copying involved.

Ah now I understand you, that advice is when you send complex data over a global cable, but the default operational mode of just sending a single numeric value is fast and realtime capable.

Wait, we can do synchronous global cables?

How fast will this be? We aren't talking sample accurate audio thread type fast are we?

Sure:

Is there a way to pick up event data callbacks (event data reader node) directly inside of a c++ node?

Yes:

// instantiate this as a class member and forward those callbacks to it:
// -prepare()
// -reset()
// -handleHiseEvent()
scriptnode::routing::event_data_reader<NV> obj;

// somewhere where you want to check if there is a new event data value:
double mv;
if(obj.getWrappedObject().handleModulation(mv))
{
	// there's a change in the event data
	// do something here...
}

}

@Orvillain said in Global Cables Don't Work when compiled:

when I compile a plugin, does that automatically compile networks, or only if the network has the allowCompilation flag enabled?

It does not compile any networks automatically - we've been over this a few times and there is literally no solution that won't mess up any workflow.

If you're writing C++ nodes, you shouldn't touch any scriptnode network at all but directly add it into the hardcoded FX modules, this way you have no overhead & the best development experience.

@Christoph-Hart haha, My Funky summary, lol that autogenerator has gone crazy...

@Orvillain data.sampleRate should be populated with the file samplerate if the audio buffer comes from an external file.

@Orvillain yeah there's currently not a real line of communication for MIDI messages back from scriptnode, but you're pretty good on track with the global cable approach - just analyse the audio in the C++ node and send it back to HISE via a global cable, then attach a synchronous script callback there that will add an HiseEvent to the MIDI queue with Synth.playNote() et al.