Scripnote Error @Christoph-Hart

[Christoph Hart]

Don‘t use scriptnode in an actual project until the rewrite is done. (especially not the stk stuff)

[ustk]

@Natan and the answer is always the same about current DSP issues, Christoph is rewriting the whole thing and no support is done to fix older bugs. My words don't mean to speak for Christoph but since the whole rewriting is a titan job, I wouldn't see him working on things that belong to the past, it would be losing time. The important thing imho is to wait for the new release, which will be killer compared to what we already have. Christoph seems to be extremely busy, so focusing on the next version should be a priority (at least regarding Hise, because I'm sure he has other projects aside...)

[Natan]

@ustk Thank you Sir For explanation, We Already Talked in another Thread.
I just Trying to get is this a big or can fix With a few changes.

You may seen thay Christoph Do Corrections in Speed of light.
I really Need this Bad, And can't wait 2 Months For The next Release :(

[d.healey]

@Natan

I just Trying to get is this a big or can fix With a few changes.

The whole of scriptnode should not be used, even if this little thing was fixed scriptnode as a whole is not production ready.

And can't wait 2 Months For The next Release

Yes you can :) you have no other choice.

[DanH]

I have a couple of basic Script FX modules in something I'm about to release.. Seems perfectly stable. Should I be worried?!

[d.healey]

@DanH Have you successfully exported the nodes and built your plugin with them?

[ustk]

@DanH I think if it is simple enough, stable, and not too cpu hungry, then I see no reason not to release it. Moreover it can be part of an update of your product later on

[DanH]

@d-healey do what? Do I need to export the nodes? One's a simple Chorus and the other just a filter...

And yup gone out to 30 beta testers and no issue thus far (with that part of the plugin anyway!)

[d.healey]

@DanH As far as I know the point of scriptnode is to build DSP units using a node graph that you then export as C++ modules and import into your project for the final build. Exporting a plugin with a node graph would be quite inefficient (CPU wise) I think. https://docs.hise.audio/scriptnode/manual/cpp_generator.html

[DanH]

@d-healey

:man_facepalming:

[Christoph Hart]

Well it depends, if you just slap a few nodes together it's fine (actually the performance is better than using HISE modules for this since the overhead of the HISE architecture is slightly higher than just the node API).

However as soon as you start modulating on sample level or use excessive oversampling in combination with a complex node setup, you definitely might want to export it to C++.

[Natan]

@Christoph-Hart Christoph, You Have any Lines On Those 2 STK Nodes I Mentioned Above?
Why They Showing Errors?

But They Work Just Okey!!!

[DanH]

@Christoph-Hart just going through the motions of recompiling - Xcode has thrown an error - Do I have to export each and every container as a CPP class used within a 'master' container

• and should I use Custom or Project?

[Christoph Hart]

@Natan said in Scripnote Error @Christoph-Hart:

You Have any Lines On Those 2 STK Nodes I Mentioned Above?
Why They Showing Errors?

No clue, but I doom the day I wrote that halfassed STK wrapper...

Do I have to export each and every container as a CPP class used within a 'master' container

Nope, the entire container will be compiled as one class. WHEN. IT'S. READY. :)

[DanH]

@Christoph-Hart Gotcha