Old Csound modules migration

Hi rackers,
for those of you who remember this experimental, unofficial project, I found some time to port this old fork of the VCV_Csound plugin to v1. I posted a Windows build in the release page, but if someone would try Linux or Mac builds it should be possible (not for me, who am a billygoat).

Pre-requisite: Csound has to be already installed in the system you’ll run Rack onto.

Disclaimer: VCV_Csound is the original name of the Github repository, I assumed it as it was, but I wonder if it is not breaking some brand IP policies by any means.

But what was this project about?
I am not the first developer, to begin with. The original project was a collection of modules that leveraged the Csound engine/API in the context of Rack runtime execution environment. The original developer was simply signing in as René, and used the Djack13 nickname on Github. There’s a web-trace here, but at the current time he disappeared and I have no mean as I could get in touch with him.

The Csound modules were simple, hard-coded modules, implementing a 1-to-1 equation: one module for every Csound script, with custom hard-coded parameter mapping and a custom UI for each module. Yet I found the graphics was pleasant, and the concept intriguing.

The plugin got only a really fast appearance in the Rack library, mainly because it’s dependant on third-party software (exactly the Csound suite, you guess) to be installed in the host machine. It’s a thing that reliable and tested cross-platform static linking and packaging of the engine with its universe of dependencies and opcodes in a Rack plugin is quite difficult to reach out. So trying dynamic runtime linking with system-wide registered Csound core libraries was the preferred way to go.

I happened to fork the original repository, simply to try and fix issues in the Windows build, when Rack was galloping fast with a tumultuous development in its v0.6++ era. Then I forgot all about it. At some time, I found that the original repository was removed from Github. So I think I will archive it, but having some spare time these days due to the Covid nightmare, I spent some of that time to migrate the plugin to v1, as if it were an “industrial archeology” project in the Rack world.

I have not updated the original readme file accompanying the 0.6x releases, but the notes included in the readme.windows version are still valid (and can hopefully be a guidance for building in other platforms). The Csound version amongst which I tested the build is now 6.14 (the current latest release of Csound), but the 6.11 version referenced in the readme.windows should still be valid altogether.

Anyway, and to conclude, for other users interested in Csound integration with Rack, I can’t help pointing out the Cabbage frontend and the development of the CabbageRack plugin, both projects by Rory Walsh, a real Csound master (among its other merits).

Ciao, and “stay safe and racking”.


Ciao Andrea. Unfortunately, there are still problems with Cabbage as you can see here:

Yes, afaik, the v1.0 branch release tag of Rory’s project is still marked as “work in progress - not ready for public consumption”. But I haven’t already tried more deeply the Cabbage export to VCVRack feature.

EDIT: I cloned the CabbageRack project and tricked a bit with the makefile, the manifest and the asset renaming, following the given instructions. The project builds and the result is exactly what we see in the screenshot from the Cabbage message board thread. It looks like the automatic widget generator code needs only some adjustment based on the latest Rack SDK or API specifications. The project moreover is really nice.

As for the Cabbage Csound frontend, the Export for VCVRack otpion looks like a facility to automatically build the plugin from Csound scripts, without having to deal directly with C++ programming and make builds. Actually, I installed the latest official downloadable version of Cabbage (for Windows), that is version 2.3.0, and in my experience it has an issue with exporting the Init symbol in the delivered plugin.dll, but I see that Rory is dropping automatic CI builds while fixing things, in the meantime. I think it’s convenient to follow the Cabbage message board for updates about upcoming features, fixes or patches, and future beta or releases of the sofware.