Dave,
Can you do me a favour and list what files you have in this directory after building SC?
dep/supercollider/build/lang
I think I may have discovered what my problem is.
Cheers.
% ls
CMakeFiles CTestTestfile.cmake Makefile cmake_install.cmake libsclang.a
lin-arm64 syncing to gdrive (usual place). No faust but python enabled.
Thanks, that’s cleared up a couple of errors, now to see to the rest…
Cheers!
1 Like
Yylex is created as the default name by lex/flex tokenizer generators. If you are using gnu flex in the build you can set a namespace using a define or a directive in the .l file. It seems by default faust and sc don’t do this hence the collision on generated code.
So either look for a lex namespace option in the cmake or edit then .l to add a name directive which is toolchain appropriate and upstream it is my best guess.
You may alternately be able to mark the symbols as non exported in the .a or add a namespace at linker time but I’m less familiar with that and have only done it with visibility in dynamic libs
Sorry if you knew all this and it wasn’t helpful
1 Like
Looks like faust already thought about this at least with the -P option here
1 Like
As per this post: Is this still a live project? · Issue #64 · VCVRack/VCV-Prototype · GitHub if anyone wants to play with this while a redesign is in the works, then fork/download from this branch:
If one is using Windows, then edit this Makefile line to = 0 to switch off SC which still isn’t fixed yet.
This will give you the following engines:
- QuickJS
- LuaJIT
- Vult
- PureData
- Faust
Have fun!
[edit: PSA: I should warn people that any patches you make with this updated v2 version will more than likely break in the future; certainly Prototype v1 patches will not work.]
1 Like
Amazing stuff happening here on the VCV Rack platform.
Who would have thought, some years ago, that a platform like VCV Rack would even exist now? And that so many would invest so much of their time and effort in expanding and improving the platform and helping out others. A huge “thank you” to the creator and all contributors
These prototyping options most likely spark loads more creativity. As with all communication, it is best done in the language you are most proficient in. Language is about sharing meaning (man-man or man-machine). Any common shared language that helps in sharing meaning accross domains is a great asset.
Many languages can be translated to other languages. Although not allways expressing the exact same meaning after translation. But still: I guess most formal languages like programming languages or “code” can be mostly translated to other programming languages.
In the case of VCV Rack, I guess there are translators available to get from these various languages to VCV Rack c++. Or at least get you pretty far on the way.
I guess AI Language Models, especifically when trained specifically on programming languages, will soon get even better in “understanding” language and “translating” from one language to another. Adding to that the translation from human “natural language” to any programming language and vice versa (e.g. explain “code”). Thus be a partner in gathering and expanding knowledge, sparking creativity and supporting or even executing the actual implementation.
Already a generic Language Model / Transformer like chatGPT (GPT) can be a great sparring partner and even coder/debugger/explainer. Although, for now, its knowledgebase has a cutoff date in 2021. So, it has little knowledge VCV Rack 2, and the explosion of VCV Rack related code in the various GitHub repositories. But…all in good time. It’s already mind boggling what is possible and widely available now.
Anyway.
Great work. Thanks to all involved.
3 Likes
Status report: I can build Prototype with working Faust or working Supercollider but not both. Everything else is no problem. I understood (?) @baconpaul’s message and tried renaming things in SC3’s PyrLexer.* and bison code in the lang directory, got no joy. Builds failed with very little error messaging, I’m not even sure where things are going wrong. At any rate, the SC3examples worked, as did the examples in the other supported languages. Alas, the details of flex and bison are beyond me. Clearly I could use a brief tutorial in how to avoid this kind of namespace collision. The build error I posted tells me what files are producing the error, I assumed I’d need to work on those files. I suppose it’d help if I knew what I was doing. 
Btw, I’m using Steve’s v2-tmp repo.
1 Like
Does it build on macos? Edit: No it does not.
I let the Faust team know. I think the thing to do is uncimment out that makefile line I highlighted and rebuild Faust clean and see what happens
Slightly tangential.
Since Cockos Reaper (the DAW) supports lua scripting (in ReaScript) I have had a try with that in recent years.
Many things lua in a curated list of quality Lua packages and resources:
2 Likes
I edited the Prototype Makefile so:
DUKTAPE ?= 0
QUICKJS ?= 1
LUAJIT ?= 1
PYTHON ?= 0
SUPERCOLLIDER ?= 0
VULT ?= 1
LIBPD ?= 1
FAUST ?= 1
I uncommented the line in faust/compiler/parser/Makefile and rebuilt the Faust stuff. Again, no problem with the build, and the examples work in Prototype. But if I edit the Prototype Makefile so:
DUKTAPE ?= 0
QUICKJS ?= 1
LUAJIT ?= 1
PYTHON ?= 0
SUPERCOLLIDER ?= 1
VULT ?= 1
LIBPD ?= 1
FAUST ?= 1
Then as noted before, running ‘make’ will end with the following error:
duplicate symbol 'yyerror(char const*)' in:
dep/lib/libfaust.a(errormsg.cpp.o)
dep/supercollider/build/lang/libsclang.a(PyrLexer.cpp.o)
duplicate symbol 'yylex()' in:
dep/supercollider/build/lang/libsclang.a(PyrLexer.cpp.o)
dep/lib/libfaust.a(faustlexer.cpp.o)
duplicate symbol '_yytext' in:
dep/supercollider/build/lang/libsclang.a(PyrLexer.cpp.o)
dep/lib/libfaust.a(faustlexer.cpp.o)
ld: 3 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [plugin.dylib] Error 1
Oh well. I have occasion to use Supercollider, but I don’t use Faust very often and can probably live without support for it in Prototype. OTOH, if there’s a way to resolve this issue then I’m happy to have both supported.
Apologies for repeating all this, I just want to be clear about where I’m at with the build right now.
Best regards,
dp
yeah if i could make the thing build on my mac i would be able to see the fix i’m sure.
but did you make or make dep after you made the faust change? you will need to cleandep / dep to get the change applied
Dave,
This may help. The following commit has been made to Faust: Use FAUST prefix in lex/yacc parser. · grame-cncm/faust@cb8d0a2 · GitHub which includes changes hinted at by Paul’s post above: Vult on VCV-Prototype works again - #18 by baconpaul
However this has been made to the master-dev branch, which is the latest version branch. So what you could try is to delete/backup the faust directory in /dep and edit Prototype Makefile thus:
$(libfaust):
cd dep && git clone -b master-dev "https://github.com/grame-cncm/faust.git" --recursive
You’ll also have to remove this line: cd dep/faust && git checkout 1dfc452a8250f3123b5100edf8c882e1cea407a1
In addition, if you get a configuration error such as: CMake Error at CMakeLists.txt:226 (target_sources): Cannot specify sources for target "faust" which is not built by this project.
you’ll need to alter line 6 of dep/faust/build/targets/interp.cmake
and change ON to OFF as per line 4.
This will build the latest v2.58.9 version.
HTH.
1 Like
Thanks, Steve, that did the trick. I’ve successfully built and tested Prototype - with all supported deps - on VCV Rack 2.2.3 macOS x64. I’ve run various Lua, JS, Pd, SC3, Vult, and Faust example scripts, it’s been all good so far. I’ll continue testing this evening.
Many thanks to you and @baconpaul for getting us to the solution !
Best regards,
dp
4 Likes
You’re very welcome! Glad to hear it.
I’m currently trying to figure out what changed between the last release v2.54.9 (Dec 2022) and the latest dev version that borks Prototype into not initializing the Faust engine after loading a script on Windows.
If I can’t figure it out I’ll try and roll back through the commits to find the last one that works. At least I got a build working with everything apart from SC3.
Cheers
Steve
Do you get any error ?
2 Likes
you should be able to make that change also with -DINCLUDE_DYNAMIC=OFF when you run the first cmake rather than editing the source (but will need a clean build when you change it since it is a CACHE variable)
That’s a good point, I often forget to check whether I can use a flag in the Makefile as opposed to editing a file after cloning.
Yeah I had to restart the build because that config error I mentioned in my post above to Dave stops the build in it’s tracks if one uses the master-dev branch - on Windows anyway i.e. INCLUDE_DYNAMIC=ON
If you use a tagged master branch commit or edit Makefile to wget the source archive e.g. https://github.com/grame-cncm/faust/releases/download/2.54.9/faust-2.54.9.tar.gz then you don’t have to use that flag as it’s OFF by default.
Found the problem: in my various tryouts of different versions of Faust I accidentally deleted this file when using the latest dev version. It’s not a standard Faust lib.