What is the process for writing my own module (not scriptnode)
-
@griffinboy woah thats sick.
-
Noice. Are you doing any kind of band limiting with the drawings to reduce aliasing?
-
@griffinboy Coool!!! I've done this a while back using a hidden sliderpack with 1024 sliders with a drawing method and a SNEX node if I reckon well. It was working but wasn't very effective and aliasing was awful. Yours seems to be very responsive!
-
@griffinboy yes - very impressive - so you are going to use this to build a poly synth?
HISE Development for hire.
www.channelrobot.com -
no that's next. I'm either going to use the Vital or Serum method. Serum's is simpler so I might go with that. Precomputed mip maps using fir filters. Easier to program but it will use a lot of memory... Maybe I'll end up switching later down the line to a realtime FFT based mip map method like vital!
There is clear aliasing in the video - but it's not 'awful' that's probably because I am processing the drawing in real time using a buffer. I've got interpolation between a few different points using splines. I'm probably going to expose smoothing as a parameter for the user. This wasn't done to affect the sound of the waveform, I am just ocd about drawing shaky lines
-
@griffinboy
This looks great! :-)
Do you have any kind of hint how to realize this? -
@griffinboy Nice!
-
@griffinboy said in What is the process for writing my own module (not scriptnode):
Precomputed mip maps using fir filters. Easier to program but it will use a lot of memory...
Yup, that's what I'm doing with the wavetable synthesiser module too. Sounds good enough for me.
-
That's good to know.
Doesn't it use a lot of memory? You'd have to store maps for each wavetable frame right, for various octaves?
Did you find a way around this or is that just the cost of precomputation?Vital gets around the memory issue by creating mip maps in real time. You probably already know, but it stores waveforms in the freq domain, silencing aliasing bins, and then inverse fft. Super nice, but the optimization sounds far more challenging since now the burden is on the cpu for efficient realtime fft.
-
This is potentially for a commercial project,
However if my the client says it's okay, I'll share how to do this.It's about time for a new c++ node tutorial I think...
-
@griffinboy
I'm keeping my fingers crossed for the project! :-)
But yes - a new C++ tutorial would be great! :-) -
Doesn't it use a lot of memory?
Less than samples lol. Something like 50-100MB per wavetable is completely neglible considering the fact that people are raw-dogging their uncompressed filmstrips into the system memory without hesitation.
-
Good point
-
I think a third party node collection (like we did with LAF), would be very useful.
-
I've been wanting to.
But the interface for 3rd party nodes is still a bit shaky.
For instance I share things on the forum, but there is setup required for each of the nodes, and these are simple nodes.If we could get a Hise feature that could allow the safe importing of nodes into a project that would be neat. At the moment you can break nodes if you drag them into a project and try to compile them, you need to actually go through the process of using the create c++ode feature, and then compile (in order that hise creates all the correct files behind the scenes) and then you replace the node code with the external node...
Also any nodes (such as my recent one here) that uses global cables, will only work in the project where the cables exist exactly the same way, because the c++ code inside the node n references the hise cables directly. We don't have agnostic input output ports for data in the nodes, excepting external data.
Maybe if we could pass data through external data that would provide a more general interface... I don't know.
But as it stands it's kind of difficult to share nodes because of these things. Although a collection of examples would probably be useful nonetheless.
-
At the moment you can break nodes if you drag them into a project and try to compile them, you need to actually go through the process of using the create c++ode feature, and then compile (in order that hise creates all the correct files behind the scenes) and then you replace the node code with the external node...
The only thing that is needed is the
node_properties.jsonfile in the Third party node folder - if you copy that file (or manually merge the JSON objects) you can just paste in the files.Also any nodes (such as my recent one here) that uses global cables, will only work in the project where the cables exist exactly the same way,
The global cables are identified through their hashed ID (that's what that boilerplate code generator is doing) so if you use the same cable names they will work across projects.
-
Ah so I was being presumptive!
Thanks for clearing this up.I guess the only manual things would be to make sure the JSON is up to date, and with GCs, making sure that the 'cable_manager_t' that we subclass the node from is aligned with the users project.
-
@griffinboy I am waiting for your all tutorials.
-
@griffinboy said in What is the process for writing my own module (not scriptnode):
no that's next. I'm either going to use the Vital or Serum method. Serum's is simpler so I might go with that. Precomputed mip maps using fir filters. Easier to program but it will use a lot of memory... Maybe I'll end up switching later down the line to a realtime FFT based mip map method like vital!
Please pardon my dumbness, but I don't really understand mip maps of FIR especially in this context.
To me, it is useful when the waveform is "as is" and not user modifiable, so it is stored with a limited bandwidth upfront.
But if you draw the WFs realtime, how would you get benefit from a mip maps of FIRs?
In this case, wouldn't dropping a single FIR (or any aniti-aliasing filter) at 20kHz (or below the current Nyquist at SR anyway...) be simpler and still effective?Got a nice lecture on the topic?
-
To start off, putting a single filter at 20k (or Nyquist) on the drawn waveform will not solve the aliasing, because the signal has already been sampled, and therefore the aliasing has already happened. If we oversample the signal by a large amount and then do what you said, yes, this method will work. However now you have a sampler + filter running at 8x oversampling using a ton of cpu. And this can't be precomputed (filtered once only), because if the user plays a higher note, harmonics will pass nyquist again and cause aliasing.
Therefore one solution is to precompute anti aliased versions of the sample at different pitches, removing high frequency content that would alias for specific note ranges. This is called mip mapping. We are essentially decimating the signal (removing high frequency details) for pitches that we play higher up.
I only mentioned fir filters because you can use them also to reconstruct the continuous signal using a certain method detailed in the paper titled 'quest for the perfect resampler'.
Another popular method is to use FFT and cancel out the high frequency bins (vital / serum).
