Scriptnode export issues

[d.healey]

@crd No that's only used if you make your own c++ nodes

[crd]

Problem solved. Creating entirely new projects/network files fixed the issues I was having.

[DanH]

@crd So... if we create a brand new project etc, should we be able to move the dll between projects?

[crd]

@danh yup!

[DanH]

@crd just copy the dll files into the new project or?

[crd]

@danh I believe if you move the dll file and the xml file you should be able to open it in a new project.

To deal with my issues, I am avoiding anything that needs compiling which I was able to do.

Re-doing the network in a separate project, making sure it exports there, then bringing it back into my actual project by coping and pasting the xml of the network.

[DanH]

@crd I tried this and got an error on the node but managed to recompile the node in the project anyway. So all good. However the exported standalone won't open - instant crash like before. Are you experiencing this?

I'm trying to export a debug build but running into errors such as:

error reading '/Users/DanH/TEST/Binaries/JuceLibraryCode/include_juce_product_unlocking.mm'

and other juce files.

If I open the .mm file I get another error:

Cannot open file '/Users/DanH/TEST/Binaries/JuceLibraryCode/AppConfig.h': Operation not permitted

I can open the AppConfig file just fine in XCode.

Anyone having similar issues?

[DanH]

@danh Managed a Debug build on a different machine and older version of develop, here's the crashed thread report, in case it means anything to you @Christoph-Hart

[Dan Korneff]

@danh I"m getting buffer issues with scriptnode plugins as well.

[DanH]

@dustbro Is that what the report is showing?

[Dan Korneff]

@danh 11 of the 15 lines related to your plugin point to AudioBuffer. The others are referencing your audio device.

[DanH]

@dustbro Ok thanks for looking! The project is literally a waveform generator and the script fx. I'll try a super simple script fx but I think the result will be the same!

[DanH]

@danh yup, same result! Hmmmm... What to do

[crd]

@danh I can't be much help. It must have something to doing with compiling the dll file because my scriptnode stuff is exporting well, without creating the dll. Maybe raise an issue here so Christoph will see it?
https://github.com/christophhart/scriptnode_testsuite

[DanH]

@crd yep exporting without the .dll is fine. Some people seem to be exporting their plugins with .dlls though, I'm just confused as to how lol

@dustbro are you exporting ok with .dlls?

[d.healey]

@danh said in Scriptnode export issues:

Some people seem to be exporting their plugins with .dlls though, I'm just confused as to how lol

I think there is a misunderstanding here. When you go to compile your scriptnode network it doesn't just compile the network you have open, it compiles all of the networks (xml) in your networks folder that have the compilation flag enabled and puts them into a single DLL. If any of those networks has a bug or is uncompilable for some reason then the compilation will fail.

So you need to test your networks one by one to make sure they compile successfully. Those that you don't want to compile must have their compilation flag set to disabled.

[DanH]

@d-healey I put a reverb in a container - basically as simple an effect as I could, to make sure that there wasn't this issue.

[d.healey]

@danh If it's a convolution reverb it's uncompilable.

[DanH]

@d-healey it's not and I tried with a simple chorus yesterday

[crd]

@danh It seemed like yesterday you were able to compile a dll for something ?

The process is definitely finicky. My goal was only to get a version of my project exported for someone I am working with, not to optimize it yet by compiling a dll of the scriptnode network. One thing I was missing (which may or may not be helpful to you) is each part that needs to be wrapped has to be wrapped individually. I.e if you have two timers in a container, each must be wrapped separately. Each wrapped file get's it's own xml file which the network file references. The network refers to all the xml files in the hise dsp network folder, regardless to whether or not they are actually present in your instrument and it will try and compile everything that you haven't manually marked to not be compiled. Definitely tedious but not impossible.