What is the process for writing my own module (not scriptnode)
-
@Christoph-Hart Right! That is really cool! I'll dig into this when I get some chance and see how I can leverage this kind of system for my thing.
-
@Christoph-Hart I think this is going to be amazing. Been looking at the snippet, and it mostly makes sense. Being able to throw data from a custom node to the UI is exactly what I want to do.
So ultimately, consider the title of this thread to be null and void - custom node is where it is at! I've just got to port my HISEscript over to c++ and start properly learning scriptnode.
-
Thanks, I'm already making use of the new Global Cable feature!
It works great.Here we are sending the drawing straight from Hise into a c++ node for playback!
-
@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.
