Transient detection within a loaded sampler - SNEX ????

[Orvillain]

Is this a job for SNEX???

I'm daydreaming about slicing up drum loops based on transients, and pondering how to achieve it.

[d.healey]

@Orvillain Is the end result to create separate samples? If so, does it have to be done in HISE?

[Orvillain]

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

@Orvillain Is the end result to create separate samples? If so, does it have to be done in HISE?

End result would effectively be a list of transient positions, essentially a list of sample start positions.

If I was building it in Python, I'd still have one sample loaded and I would just index an array o f sample start positions when activating a voice.

You could n theory have an "export slices" feature which would create separate samples, but no. That isn't the purpose of this, and my aim isn't to create separate samples as such. Rather, my aim is to create a loop slicing playback engine.

[ustk]

@Orvillain I think there are several techniques to detect transients, and it is often a blend of many of them.

• It depends on the frequency (so I think that it shouldn't be bad to "listen" to a certain frequency range)
• apply an exponential factor to the signal in order to improve the ratio of the transients it contains
• don't detect below a certain threshold (but that becomes amplitude dependent)

Why taking not the derivative of the amplitude and check for the a minimum slope... but that is just an idea, and here again the input has to be filtered

if the detection is not real time, I would probably go with a waveform detection above a specific threshold, and prevent to detect the next transient after a specified amount of samples. Well, after thinking to it this can be real time too...

[HISEnberg]

@Orvillain Did you ever make any progress on this? Looking into something similar for a custom audio file player I have and am wondering if you have some recommendations!

[Orvillain]

@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.

[Orvillain]

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]

@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!

[Orvillain]

@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;);

[HISEnberg]

@Orvillain Niiiccee thanks this is precisely what I need. I agree the create C++ code for global cables is a bit clunky but once you get the hang of it it's not so bad. Here is the doc I think you are referring to:

https://docs.hise.dev/scriptnode/list/routing/global_cable.html