I have no idea what you just typed lol 
I think you meant this?
Downloads 
This is a great piece of software. any chance there are plans to get this to work on a raspberry pi?
I tried building on a pi4 but didn’t get far, some immediate errors cropped up in the make. Let me know if you’d like me to post errors (or if I should just post an issue on github). I wanted to clarify if that was something you were willing to support but if not it’s still cool software and thank you for sharing!
I have no clue about rpi.
Please try compiling the dpf examples.
If they work we know it’s doable.
if they don’t, please file an issue at github for DPF.
1 Like
There was a bug but falktx fixed it immediately. Can you describe what the steps are for preparing ninjas 2 for install via dpf (or would I just build from source)? This is a bit unclear to me. Thanks, this would be huge!!
Build instructions
Dependencies
libgl1-mesa-dev
libx11-dev
libsndfile1-dev
libsamplerate0-dev
If you want a standalone jack binary install either libjack-dev or libjack-jackd2-dev
git clone --recursive https://github.com/rghvdberg/ninjas2.git
cd ninjas2
make
There is no make install, binaries will appear in /path/to/ninjas2/bin/, just copy the binaries to an appropiate location.
1 Like
Autobuilds for develop are up. Currently only lv2 works.
Will fix vst tomorrow.
1 Like
Windows / Mac vsts are up.
Hi @rghvdberg and thank you for your obvious patience. I should have specified I’d tried to build in every way I could think of, and wasn’t sure if I was doing something wrong, but if the standard protocol is indeed supposed to work then there is an indeed an issue (despite being able to build the dpf examples properly). I’ve created an issue here to document. Thanks so much - ninjas2 works great on my laptop and it’s a great piece of software, I would greatly appreciate getting it to work on the pi!
Found it : the aubio make file isn’t part of dpf. I’ll try to edit it in the same way as the latest commits in dpf.
1 Like
Is something I could help facilitate in any way? If I could be of any use I would be more than happy to put in some work to contribute!
On that note, I’m curious about the possibility of a feature that would allow you to send commands (osc, midi, or via api or something) to in any way automate the loading a file rather than through the gui? Or maybe you have a suggestion for the possibility of loading samples without having to navigate the gui via mouse (the only workaround I’ve seen as a possibility would be xdotool). Again, anything I could to help (sorry I’m not a more advanced programmer at this point), let me know! Much appreciated
@rghvdberg Just curious do you think this might work if I reverted to older versions or would the aubio still be the dependency issue?
Totally forgot you can use system aubio with ninjas2
make USE_SYSTEM_AUBIO=true
that will skip the aubio stuff in the source tree and just use the aubio installed on your computer.
Install the aubio development package first of course. Probably something like libaubio-dev.
1 Like
Thanks very much for trying to help me make this work (I swear I won’t be the only one with a Pi who wants to use this!!)
But hmm. unfortunately
gives me the exact same error message. So it’s still trying to use the aubio in ninjas2/aubio?.. Tried removing the aubio directory and still got the same g++ errors but looks like this…
$ make USE_SYSTEM_AUBIO=true
make -C dpf/dgl
make[1]: Entering directory ‘/home/pi/installed_local/tryninjas/ninjas2/dpf/dgl’
Compiling src/Application.cpp
g++: error: unrecognized command line option ‘-msse’; did you mean ‘-fdse’?
g++: error: unrecognized command line option ‘-msse2’
make[1]: *** [Makefile:104: …/build/dgl/Application.cpp.o] Error 1
make[1]: Leaving directory ‘/home/pi/installed_local/tryninjas/ninjas2/dpf/dgl’
make: *** [Makefile:33: libs] Error 2
Trying to find similar errors for arm issues and a falktx fix got pointed to which kind of seems like gold. If I knew what to do with that code I would but maybe that’s an insight that could be helpful?
Hopefully this isn’t all too troublesome: again grateful for the help
It looks like the makefile is trying to use the SSE processor extensions, which I do not believe exist on an ARM processor (They would be x86 instructions). I believe there may be similar instruction sets for ARM but won’t be SSE. The diff for the makefile you posted is removing the instructions to try to compile with SSE is all it appears. I haven’t looked at Ninjas build software but I would be looking for something similar in those makefiles.
SeabladeTry this.
Get rid of the dpf fork I’m using. Just remove the whole dpf directory.
Then download dpf from github and put it where my dpf dir was.
vst and jack will be broken though. Only lv2 will work with this dpf.
This still requires make system aubio ofc.
1 Like
Hey @rghvdberg thanks for the suggeston. The good news is it built! (I tried with and without system aubio, both were able to build but both had same issue as far as I could tell.
So the lv2 does ‘load’? (in carla) but all I can see is the generic controls (which are useless without a loaded sample obv). When I try to use the custom GUI it hangs. Strangely I tried this on raspbian stretch first and it worked in ardour but when I tried on buster it crashes ardour when I tried to load
log from carla:
assertion failure: “xWindow != 0” in file src/Window.cpp, line 288
Carla assertion failure: “fProcess != nullptr” in file CarlaPluginBridge.cpp, line 127
Carla assertion failure: “fProcess != nullptr” in file CarlaPluginBridge.cpp, line 127
and tried to run the standalone for kicks and giggles
assertion failure: “xWindow != 0” in file src/Window.cpp, line 288
Segmentation fault
Any thoughts?
P.s. Sorry for delay I’m not sure why I didn’t get an email on your last reply, but I still appreciate the help in trying to figure this all out!
Erm, that’s some scary dpf internal stuff…
dpf needs opengl so maybe it’s the graphics driver that prevents creating a window.
Also try building the dpf examples and see if they work on buster.