administrators group

Christoph Hart

@HISEnberg yup, but it's still very experimental and far from feature complete.

Christoph Hart

@Orvillain the wavetable synthesiser uses the mip map approach to get rid of upper harmonics with pretty good results so for me that's the best approach. with wavetables it's especially intriguing because you can just ditch the upper bins of the FFT data (which is a brickwall filter but since the wavetable cycle size is exactly the FFT length you don't get any side lobes or whatever it is called lol).

For mip-maps below the root note - lowpass and downsample (dsp::FilterDesign::designFIRLowpassWindowMethod then keep every 2nd sample)

Ignore mip maps below the root note - downsampling can be done in realtime without any artifacts - the goal is to remove aliasing that comes from playing pack samples that produce frequencies above Nyquist.

For mip-maps above the root note - upsample and then lowpass (use the same oversampling approach here for the upsampling and then the same kind of FIR filter???)

You need to lowpass before you upsample or the upsampling algorithm will create the alias effects.

Christoph Hart

@modularsamples global_send / receive_nodes are not polyphonic and I wouldn't recommend to expect that this change in the foreseeable future. I see a distant possibility of making this happen the same way I've fixed the global envelopes, but let's wait if that new change holds up.

However I'm currently rewriting the routing.send / routing.receive nodes to allow polyphonic support.

The clicking is barely noticeable when using the virtual keyboard for some reason.

That's because the timestamp of a virtual note is always zero so it doesn't chop up the audio buffer.

Christoph Hart

@dannytaurus not sure, it looks more like it's suited towards embedded devices. Stuff like fixed sample rate and buffer size makes it rather awkward to wrap into a general purpose API.

Christoph Hart

@DanH there's a little overhead compared to the C++ effect, but it shouldn't be too critical, so not sure if spending time is worth it in order to get it down 0.5%.

Have you profiled it with the profiler to see the exact performance difference?

Christoph Hart

you might get 90% there by copy & pasting any scripting object. There are a few virtual methods that you need to overwrite but hooking methods up is usually done through the internal Wrapper subclass and the API_VOID_METHOD_WRAPPER_X() preprocessor.

Register the class with the JavaScript Engine (no idea on how this is done).

Usually this is done by adding a method to the Engine / Synth class which creates and returns an object, just look at the myriad of existing methods like this one.

If you want to conditionally include the class without too much intrusion into the HISE codebase, take a look at how the BeatportManager / the NKS manager are integrated.

Christoph Hart

Yup the files in the additional source code folder are used when exporting the plugin. You can safely delete all files in the nodes subfolder, they are recreated when you compile the FX dll.

Christoph Hart

docs:

whatever value is set as Index parameter will cause the childnode at the respective position to be processed while leaving the other child nodes unprocessed.

HISE | ScriptNode | branch

A container that allows selective processing of its child nodes

(docs.hise.audio)

Christoph Hart

@aaronventure said in Neural Amp Modeler (NAM) in HISE:

If you use the multi node to force mono processing and before that collapse the stereo signal into mono, you get roughly the same performance.

Haha wasn't all that drama about it being 8x slower than the NAM plugin?

It would be cool to be able to embed the .nam files into the plugin instead of having to install them separately.

Can't you just embed the JSON content of the NAM file into a script and it will be embedded in the plugin?

Christoph Hart

@griffinboy just use a negative feedback value in the receive node?

administrators

Posts

HISE | ScriptNode | branch

Member List