I wrote a simple JUCE plugin to emulate damper resonance for sampled pianos. I created it using Projucer. What’s the easiest way to build it for Zynthian? So far, googling has not provided an answer that actually works.
I believe I should be able to download and build JUCE on the Zynth, and using Projucer, add a Linux makefile exporter. But is there a way that doesn’t take me down the rabbit hole of building JUCE on Zynth? (My guess is it’ll lead to a long list of missing dependencies to add.)
Right now I’m looking for simple/robust. Later if needed I can work on a faster edit/compile/test cycle.
I’m currently working on Windows with Visual Studio Community, and testing on Windows VST3. Hopefully there won’t be too many LV2 issues. I do realize the GUI won’t work (at least not yet, maybe later in Vangelis but that’s totally borked for me.)
All JUCE based plugins require JUCE. (No surprise there!) The build scripts (usually Cmake) will build JUCE. This is normal. You may be able to create the Cmake config on windows and tweak it for Linux by setting the build to LV2.
I didn’t dare to answer your similar question in the other thread because I was sure there are people knowing better, but since nobody else did I try to make some guesses: keep in mind I have almost no experience with JUCE, but I did compile JUCE third party plugins on zynthian. So I don’t know how Projucer currently works:
You may be able to “projuce” a linux makefile targetting lv2 already on your other platform (Windows) and just compile then on zynthian to get a arm64 binary.
You said in the other thread you “installed” Juce on C:/. Some people tend to include their plugin frameworks als a git submodule, and therefore in a relative path. Another advantage is that you can keep the framework stable to avoid incompatibility issues on framework updates.
So maybe just try to get juce as a submodule in your repo, projuce the makefile and pull the lot onto your zynthian.
Thanks. First, I’m using Projucer, which doesn’t support CMake. Despite being a retired software engineer, I’ve never used CMake, at least not directly, so I’d rather not go down that rabbit hole quite yet if I can avoid it.
The source code for all JUCE modules used by the project is in the project – in the github repo – so actually, JUCE itself shouldn’t be needed. But since it’s Projucer, you need Projucer to build the makefiles and set up the targets (Projucer “exporters.”)
But I guess I’ll either have to do CMake or else build Projucer on Zynth (and hope it actually works …) Unless someone knows a better way. I was hoping someone had actually done this!
This may be one of the many reasons that people start out using Projucer but switch to CMake.
Thanks – On Windows, Projucer exports for Visual Studio, and I have no idea how it puts together the make machinery for VS. (I’m also new to VS. Most of my work was embedded systems, and I tended to just use vim and make. Plus, on most projects I worked on, some other poor schmuck did most of the make machinery, thankfully.)
But maybe I can install JUCE on Ubuntu and see what kinds of LV2 exporters I can get, and maybe get a nice plain Linux makefile and copy that over.
Thanks for the tip about submodules. I’ve never plumbed up one of those myself, but will look into it, as anything that manages dependencies better than README is a good thing!
I really don’t think it’s needed, since all the JUCE modules code is in the PianoRes repo (Projucer put it there.) I think I only need JUCE to build the makefiles and build-directory structure. It depends on whether there are any JUCE executables, like helper tools for building specific plugin types.
I think the Projucer made a project which included and linked your juce modules in the project file but not in the file system.
I bet if you manage to prepare a linux lv2 makefile build environment, compilation in another place will only work if you keep your relative paths intact.
Some years ago I noticed that my Juce compiled lv2 produced an heavy library (it seems to me about 40MB) where many other lv2 have a library of a few KB.
Then I switched to a handmade lv2, building it from scratch. Its size was reduced to some KB.
I think the smaller size introduce some performance improvements, so I suggest you not to waste your time in cross compilng with Juce, use it to drop Juce away and use just C with no frameworks.
Thanks for mentioning that. I only used submodules once and they were set up by the project guru and all I recall is that everything was a bit more complicated! But in this case I suspect it’s a clear winner, so I’ll have to study up and figure it out.
First, though, I’m going to try to build for Linux, which should be fairly simple (after ferreting out all the dependencies.) I run Ubuntu on WSL and WSL can now access OneDrive where my code is. Once I get that sorted, I’ll give RPi a try.