Vult on VCV-Prototype works again

I have fixed the code of the VCV-Prototype in order to run Vult and LuaJIT code.

If you want to use the VCV-Prototype you have to build it yourself. Here are the steps to do it.

1.- Delete your old VCV-Prototype repository. It is better to start with a clean repository.

2.- Clone the repository with

git clone https://github.com/VCVRack/VCV-Prototype

3.- Enter the directory with

cd VCV-Prototype

4.- Checkout the code for Rack v2-tmp

git checkout v2-tmp

5.- Initialize the submodules

git submodule update --init --recursive

6.- You need to have premake (version 4 or 5 installed). In linux you can do

sudo apt install premake4

On mac

brew install premake

I have not tested windows.

7.- Turn off the unused engines. Since I don’t know the status of the other engines, I only enable Vult, JavaScript and LuaJIT. You have to edit the Makefile to look like this

QUICKJS ?= 1
LUAJIT ?= 1
PYTHON ?= 0
SUPERCOLLIDER ?= 0 # disabled
VULT ?= 1
LIBPD ?= 0 # disabled
FAUST ?= 0 # disabled

8.- Build the dependencies with

make dep -j

9.- Lastly, you can build and install the VCV-Prototype with

make -j install

As I mentioned above. I have not tested it on Windows. If you have a working development environment on Windows please give it a try.

15 Likes

FYI:

That would only work for a contributor with access rights.

For anyone else you would use: git clone https://github.com/VCVRack/VCV-Prototype

2 Likes

Thanks! I updated the steps.

In fact you could remove steps 3 & 4 by using:

git clone -b v2 https://github.com/VCVRack/VCV-Prototype && cd VCV-Prototype

This will clone the repo and checkout the v2 branch, then cd into the directory in one step.


It’s been a while since I worked on this, and am putting some PR’s together, to bring parts up to date.

@ dizzisound has done a Windows build with QuickJS, LuaJit and PureData enabled here: building with libpd support · Issue #66 · VCVRack/VCV-Prototype · GitHub He goes into what he did to get the build working on Win10 if builders are interested at having a go themselves.

This is my build with Vult enabled as well

Small test patch Prototype_Engine_Test.vcv (5.1 KB)

[edit: Update - Vult v0.4.15]

6 Likes

Hey Steve, thanks for the labors ! I have a working Prototype for v2 running on a Mac Mini M1 in Rosetta mode. Pd, Faust, Lua, JS, and Vult all appear to work okay but I’m hitting a problem with the Supercollider stuff. It builds all right but during the Prototype make I get this error:

In file included from src/SuperColliderEngine.cpp:4:
dep/supercollider/lang/LangSource/SC_LanguageConfig.hpp:28:10: fatal error: 'boost/filesystem/path.hpp' file not found
#include <boost/filesystem/path.hpp>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Any suggestions ?

Best regards,

dp

Hi Dave, cheers mate! Glad it’s working for you so far.

OK, that’s an error that’s been discussed here: [makefile] Update supercollider to v3.12 by SteveRussell33 · Pull Request #59 · VCVRack/VCV-Prototype · GitHub (the reason it doesn’t show up in Pull Requests is that I had to delete my local fork due to some problems and it closes the PR automatically.)

That’s OK as I’ve updated that Supercollider PR to v3.13 (was v3.12) onto the v2 branch not the v1 branch as it was originally. If you read the above commentary you’ll eventually see this post referenced: Build fails on Win10 msys64 · Issue #54 · VCVRack/VCV-Prototype · GitHub about adding the Boost C++ libs which is what I did to get that part of the build working the last time I worked on this.

Going back to the former commentary, you’ll see a fix that may work in getting the Supercollider part #include’ed as part of the make process for the module itself. That fix is pacman -S mingw-w64-x86_64-boost

You may, as an alternative to that, try adding -Idep/supercollider/external_libraries/boost to this line in Makefile as mentioned a few posts down in the comments above.

I’m going to test this myself later, if it works for you let me know and I’ll post a PR for it at some point.

Makefile edit work needs to be done to include the Boost headers as part of the make dep step, so that one doesn’t run into the error that you’ve posted.

HTH in the mean time, any other problems and/or edits that work for you, post them here as Supercollider is, personally, the next engine I want to get working. :slight_smile:

2 Likes

Thanks for the help, I’m getting further along. I can add Supercollider support now but not along with Faust support. I’m getting this error when building with support for both:

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)
duplicate symbol 'yyerror(char const*)' in:
    dep/lib/libfaust.a(errormsg.cpp.o)
    dep/supercollider/build/lang/libsclang.a(PyrLexer.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

Btw, the FLAGS options for SC3 are added to those used for building Faust support:

 % make        
c++  -std=c++11 -stdlib=libc++  -Idep/include -Idep/vult -Idep/include/libpd -DHAVE_LIBDL -DPDINSTANCE -DPDTHREADS -DINTERP -Idep/supercollider/include -Idep/supercollider/include/common -Idep/supercollider/lang -Idep/supercollider/common -Idep/supercollider/include/plugin_interface -Idep/supercollider/external_libraries/boost -fPIC -I../../include -I../../dep/include -MMD -MP -g -O3 -funsafe-math-optimizations -fno-omit-frame-pointer -Wall -Wextra -Wno-unused-parameter -DARCH_X64 -march=nehalem -DARCH_MAC -mmacosx-version-min=10.9  -c -o build/src/FaustEngine.cpp.o src/FaustEngine.cpp

I turned off Faust support and got working SC3 support in Prototype, though I only tested the rainbow.scd example.

Any advice on resolving the symbol duplication ?

I needed libudev-dev for super collider and foist is at 15%/55MB git. Let you know …

EDIT: I got an extra 8 gig plus from btrfs on chromebook, by a backup, delete, restore of the container. It seems not to do a background defrag/combine of older SSD sectors and runs out of space. This is ironic as obviously the static sectors part filled are better used again in a better layer levelling algol-68-o-1-less-than-prime-party-on-dudes-a-rythum of the future.

EDIT2: although I did have an cargo cult of rust install yesterday for a onefetch nice repo cd.

EDIT3: 210MB/50%, so what eggzackly is faust delivering … impulse response filters for planets?

I don’t as I’ve not added Faust yet and I’ve not got access to a Mac.

I’m still stuck trying to get SC to work, dep build works, but make dist fails:

cd dep && git clone "https://github.com/supercollider/supercollider" --branch 3.13 --depth 1
fatal: destination path 'supercollider' already exists and is not an empty directory.
make: *** [Makefile:142: dep/supercollider/build/lang/libsclang.a] Error 128
make: *** Waiting for unfinished jobs....

because for some headaching reason it wants to clone the repo again!

If true I’d likely side with smalltalk-77.

So far 2* decimation in domain fft, … hopefully there’s not a gforth.

EDIT: https://github.com/grame-cncm looks like a commit course-a-thon.

EDIT2: oooh, for a git fork-rebase-used.

EDIT3: Il foe debrassy no habla?

EDIT4:

it clone "https://github.com/grame-cncm/faust.git" --recursive
Cloning into 'faust'...
remote: Enumerating objects: 128826, done.
remote: Counting objects: 100% (3158/3158), done.
remote: Compressing objects: 100% (1108/1108), done.
73% ...

Do, de,do, da, … do, de do … Android smartkeyboard VCV context postfix eliminate ...

So happy about VCV-Prototype being v2-ized and revived! thanks

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