Compiling Faust based ScriptNodes on MacOS:Problem
-
@Lindon i noticed that after re-reading your steps. I guess I thought it would still work as the infrastructure for faust seems to be in scriptnode in the release version 4.0.0
i do wonder about compatibility issues and possible dev branch bugs so maybe ill finish off what im doing in 4.0.0 and then compile the dev build with faust after.
i am very excited about the possibilities of bringing some of the cool things ive made in faust/rnbo/gen dsp to be useful for others.
i am also keen on the scriptnode, i got a pretty unique synth in my first test
-
@AxiomCrux vgreat - I look forward to seeing what you build.
But first I think I need @Christoph-Hart to take a look at this one when he gets back.
-
@Lindon Just checked it and it compiles here fine.
So the error message says that the compiler can't find the C++ class
FaustDistTestFile
generated by the Faust compiler when trying to compile the scriptnode wrapper networkFaustDistTest
. Can you post the content of the include file found inBinaries/Source/includes.h
? -
This is how my include file looks:
// [...] #pragma clang diagnostic ignored "-Wunused-variable" #endif // Include third party header files ---------------- #include "FaustDistTestFile.h" // Include compiled network files ------------------ #include "BitRed01.h" #include "ChorusTest.h" #include "DirtModule.h" #include "FaustDistTest.h" #include "LoHiFilter.h" #include "PassThru.h" // [...]
If I comment out
#include "FaustDistTestFile.h"
, then the compilation fails with the exact message that you posted, so it's definitely failing to find the faust file. -
@Christoph-Hart well yes mine looks very differnt to yours:
/* Autogenerated include file. */ #if (defined (_WIN32) || defined (_WIN64)) #pragma warning( push ) #pragma warning( disable : 4189 4373) #else #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wunused-variable" #endif // Include compiled network files ------------------ #include "BitRed01.h" #include "ChorusTest.h" #include "DirtModule.h" #include "FaustDistTest.h" #include "LoHiFilter.h" #include "PassThru.h" #include "Phasertest1.h" #include "pingpong.h" #include "StereoDelay.h" #include "TapeDelay.h" #if (defined (_WIN32) || defined (_WIN64)) #pragma warning( pop ) #else #pragma clang diagnostic pop #endif
-
@Lindon and its definitely there:
-
@Lindon no idea then, it literally does this:
auto fileList = getFilesFromThirdPartyFolder() if(fileList.isNotEmpty()) printComment("Include third party header files ----------------"); for(auto file in fileList) printIncludeStatement();
So the question is why doesn't it pick up this file? What if you rename it? Or delete it, as it should be recreated by the faust exporter.
-
@Christoph-Hart said in Compiling Faust based ScriptNodes on MacOS:Problem:
getFilesFromThirdPartyFolder()
well I'd suggest the problem is in here:
getFilesFromThirdPartyFolder()
as its returning an empty list...
-
If I delete it and run the compile again I get the same problem - and as you say, it rebuilds the .h file...
-
if I remove the Faust node and create a new one and add a new file (called FaustTestTwo) I get the same problem , and now FaustTestTwo.h is in the ThirdPartyFolder
-
@Lindon however when I delete the file and let it get rejenerated my includes.h file looks like this:
/* Autogenerated include file. */ #if (defined (_WIN32) || defined (_WIN64)) #pragma warning( push ) #pragma warning( disable : 4189 4373) #else #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wunused-variable" #endif // Include third party header files ---------------- #include "FaustDistTestFile.h" // Include compiled network files ------------------ #include "BitRed01.h" #include "ChorusTest.h" #include "DirtModule.h" #include "FaustDistTest.h" #include "LoHiFilter.h" #include "PassThru.h" #include "Phasertest1.h" #include "pingpong.h" #include "StereoDelay.h" #include "TapeDelay.h" #if (defined (_WIN32) || defined (_WIN64)) #pragma warning( pop ) #else #pragma clang diagnostic pop #endif
So this should work now no?
But of course it doesn't....
-
@Lindon aaaaaand, now its back to this again:
/* Autogenerated include file. */ #if (defined (_WIN32) || defined (_WIN64)) #pragma warning( push ) #pragma warning( disable : 4189 4373) #else #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wunused-variable" #endif // Include compiled network files ------------------ #include "BitRed01.h" #include "ChorusTest.h" #include "DirtModule.h" #include "FaustDistTest.h" #include "LoHiFilter.h" #include "PassThru.h" #include "Phasertest1.h" #include "pingpong.h" #include "StereoDelay.h" #include "TapeDelay.h" #if (defined (_WIN32) || defined (_WIN64)) #pragma warning( pop ) #else #pragma clang diagnostic pop #endif
-
@Lindon adding the line to the includes.h file and then running from projuicer gives me no relief:
-
@Lindon did you try building it from the autogen project etc?
-
@DanH said in Compiling Faust based ScriptNodes on MacOS:Problem:
@Lindon did you try building it from the autogen project etc?
The autogen project?/What do you mean?I ran it from here:
-
@Lindon I mean build the dynlib from the AutoGenerated Projucer project rather than building it from Hise...
-
@DanH isnt that what I just did?
-
@Lindon So I copied out every network into a brand new (empty) project - and after each one ran a compile - and they all worked in turn, so its something in my project that's screwing this up but I cant work out what it could be.....
-
@Lindon OK so.....
I went back to first principles.
I deleted everything to do with HISE.....
I deleted everything to do with Faust....I downloaded and unzipped the HISE version from 10th Sept (the latest and greatest)
I downloaded the latest Faust 2.74.6
I meticulously followed the install steps......
I moved my project to a fixed drive location.....and unplugged the external drive (no sneaking back there now..)...and it built the dylib correctly, and then compiled correctly, and passes pluginval and auval
So fingers crossed this is the end of this one....
-
@Lindon aaaaand: NO.
But I've found at least one of the culprits....
HISE_USE_EXTENDED_TEMPO_VALUES=1
crashes DLL builds every time... raising a seperate bug post.