@Oli-Ullmann Yes I think you're correct. I checked the docs and there is a line about it not meant to be a dynamic state.

@Christoph-Hart

This is a bit complicated to explain. But basically.... I have a bunch of hardcoded effects. At initialisation, I create knobs in my UI.

I have a menu that loads an effect to the particular Hardcoded Master FX slot in question. When this happens, I assign the processorId and parameterId to the correct ones, and I update the matrixTargetId.

If I do this .... then my modulation for that parameter works audibly. But the UI animation, hover states, and modulation indicator completely break and stop working.

Now..... if I set the matrixTargetId when creating the parameter, and then NEVER update it...... it works fine.

I know this is a bit hard to get your head around, and maybe I'll try and make a minimal example. But as a fundamental question, do you support updating the matrix targetId parameter??

Not sure, but try putting it in a fix_block container???

@Lindon ohhhhhhhh

@HISEnberg said in Transient detection within a loaded sampler - SNEX ????:

@Orvillain Nice thanks for the tips! I'll have to look into spectral flux envelope it's a new concept for me. I'm about 40% of the way through this process myself.

Just curious how are you extracting the FFT information then broadcasting it to HISE, are you using Global Cables for this? I am trying to theorize how to make the jump from detecting the transients to updating the HISE side (transient markers, snap grid, etc.). I'm guessing just wrap all that info into some JSON and use GlobalCable.sendData to update my HISE interface and scripts!

Also agreed I'm almost exclusively doing the bulk of DSP and advanced analysis in C++ then using the HISE API and Interface builder to handle the rest, really efficient and powerful combination.

Thanks for the tips!

Yes exactly. I'm doing all the clever math stuff in c++. That gives me a bunch of transient time positions in samples. I then feed this list over to HISE across a data cable using the cable_manager in the c++ node.

Christophe had a good template for this somewhere. But in essence when you setup your node struct, you inherit:

using cable_manager_t = routing::global_cable_cpp_manager<SN_GLOBAL_CABLE(-389806413)>;

template <int NV>
struct data_node : public data::base, public cable_manager_t

{

The numbers there have to be the hashed ID of what the cable should be named. I don't really like this part of it tbh, but it is possible to setup.

Then in the constructor:

	data_node()
		: fft(//put whatever inputs you want to setup into the constructor here)
	{
                // this bit registers a datacallback function. As I understand it, any time data is sent, this function is triggered.
		this->registerDataCallback<GlobalCables::dataCable>([](const var&) {
			jassertfalse;
		});
	}

Later on you'd do something kinda like this:

// Create the JSON object
hise::JSONOBject nameOfTheObject;

// Fill it with data
nameOfTheObject[String("whatever you want the key to be called")] = sourceDataHere;

// Send the JSON down the cable
this->sendDataToGlobalCable<GlobalCables::dataCable>(nameOfTheObject;);

Use projucer to create an Xcode project.

Oh, and once I got my head around exactly how to interface c++ nodes with HISE, it has become one of my favourite ways of working. I pretty much just jump straight to a c++ node for any DSP or advanced analysis thing; whereas my very first transient detector was written in the HISE JS layer, and believe it or not it was quite good!! A little slow, but it did work.

@HISEnberg
Yes I wrote a custom transient detector in a c++ node, and made sure it utilised an audio file, which I can load in my UI using the audio waveform floating tile.

I implemented spectral flux extraction:

• Take your audio.
• Perform an FFT on it.
• Extract the spectral flux envelope from the FFT.
• Downsample the spectral flux envelope (optional but can help accuracy)
• Perform peak picking on the spectral flux envelope.

I used the stock JUCE FFT processor.

Figured it out. It does support addModulator. This is how you do it:

Content.makeFrontInterface(600, 600);

const var builder = Synth.createBuilder();
builder.clear();

const var generator = builder.create(builder.Effects.SlotFX,
                                     "generator",
                                     0,
                                     builder.ChainIndexes.FX);


const var slotfx = Synth.getSlotFX("generator");
slotfx.setEffect("Hardcoded Master FX");

const hardcoded = Synth.getEffect("generator_Hardcoded Master FX");

const numP = 4;

for (i = 0; i < numP; i++)
{
    hardcoded.addModulator(i, "MatrixModulator", "P" + (i+1) + " Modulation");
}

builder.flush();

It doesn't seem like slotfx or hardcoded support the .addModulator() method.

I've got this far. What I want to do is create a matrix modulator for the first 8 hardcoded modulation slots.

And I assume these are the modulation colour references to use:

		HiseModulationColours::ColourId::ExtraMod
		HiseModulationColours::ColourId::Midi
		HiseModulationColours::ColourId::Gain
		HiseModulationColours::ColourId::Pitch
		HiseModulationColours::ColourId::FX
		HiseModulationColours::ColourId::Wavetable
		HiseModulationColours::ColourId::Samplestart
		HiseModulationColours::ColourId::GroupFade
		HiseModulationColours::ColourId::GroupDetune
		HiseModulationColours::ColourId::GroupSpread

Is there any limitations around which colour a particular parameter should use? Or is it really just down to how you want it to appear in the module tree??

And for the ParameterModes, would it be these ????

modulation::ParameterMode::ScaleAdd
modulation::ParameterMode::ScaleOnly
modulation::ParameterMode::AddOnly
modulation::ParameterMode::Pan
modulation::ParameterMode::Disabled

Woaaahhhh that's amazing!! I really dig it! And honestly, seems so much easier to my mind than messing around with scriptnode directly.

@Christoph-Hart Can I check with you... in the c++ code do we need to do anything special to support scale/unipolar/bipolar modes ... or does that just happen automatically when using the matrix modulator as a source, and an (for example) LFO in the global modulator container (set to bipolar itself)

@Orvillain

@Christoph-Hart
https://youtu.be/-XchgrM-yR8

Things I notice, and I don't think this was happening to me a bunch of branches ago. Sorry, can't be more specific!

• Setting a parameter to use external modulation can reset all of the parameters that are already set to use external modulation, to zero.
• Right-clicking a parameter will reset any parameters that are already set to use external modulation, to zero.
• fuzzy glitching when assigned to certain parameters, even though no modulation signal is incoming.

Any ideas on those??

(btw, I've not yet tried turning modulation on directly inside the c++ code. Haven't gotten around to testing it)

I had a strange thing with this recently, where I turned on external modulation for all my parameters, and my script node parameters started resetting to zero, and causing oddness in the DSP stream and all sorts. I need to debug it, might've been a one off or a weird bug.

@d-healey said in [bug] SlotFX.setBypassed no worky:

@Orvillain said in [bug] SlotFX.setBypassed no worky:

Inside that is reg engines = {blahblahblah}

It's an object so should be const engines = {}

You can still add to the object and change the data within it, you just can't change the variable itself.

Yes I'm aware of that.

For example this would give an error

const engines = {};

engines = 10;

I'm aware of that too.

What is the benefit of using const, in my situation? The only thing I can come up with is it gives me a guard against overwriting engines. But nothing is attempting to do that anyway. Nor will it.

To my mind, reg gives me access performance benefits. Maybe that is wrong.

@ustk said in Disabling interpolation in the wavetable synth:

@Orvillain When a parameter is "modulatable", the modulator becomes the main controller, right? So why not making a scripted step modulator you can either set between the num steps you need and linear?

My modulation sources are wide and varied, LFO's, envelopes, midi controller sources, etc. So I think what I'd need actually is a way to quantize the modulation data so it fits the current frame count for the loaded wavetable.

@d-healey said in [bug] SlotFX.setBypassed no worky:

@Orvillain
reg should be used for variables declared in onInit whose data needs to be editable.

const should be used for all fixed data - arrays, objects, component references, module references, etc.

reg is more performant in real time callbacks than var but you should avoid using var any way.

All of the data inside my custom SharedData namespace needs to be editable.

I don't use var anywhere.

@d-healey said in [bug] SlotFX.setBypassed no worky:

@Orvillain said in [bug] SlotFX.setBypassed no worky:

reg variable

Use const

As I understand it, regs are more performant and are mutable. Perfect for tracking modes or current effects or effect orders, etc etc.