So excited to play with these once I have a spare moment this weekend. Id also love a brief technical write-up of how you did it for those of us new to SC development (especially new to the lower-level stuff like compiling ugens and using C libraries in them, etc)
Also that specific install path implies to me that using these UGens in a script we publish to maiden library would be rather hard, no? As maiden library just installs to ~/dust/code?
My install notes (installing directly on device - norns/shield/fates)
This was done on Fates so I’m not 100% sure all requirements/packages match up on norns hardware. Updated to work on shield (and norns hardware I believe)
# mi-UGens install and build notes
sudo apt-get install cmake
cd ~/
git clone https://github.com/okyeron/mi-UGens.git
git clone https://github.com/supercollider/supercollider.git
cd supercollider
git submodule update --init
cd ~/mi-UGens
# then cd to directory you want to build
cd MiClouds
mkdir build && cd build
cmake -DSC_PATH=~/supercollider ..
make
I think you can do git clone --recurse-submodules on supercollider, but I did it in two steps because I’m a noob.
the compile process generates a .so binary in the build directory which I then copied to a new directory along with the original .cpp and associated files. Those then get installed at /home/we/.local/share/SuperCollider/Extensions
NOTE - however I did need to hack/change the CMakeLists.txt for a couple modules. See here
Did you literally take these steps on the norns? Or on your computer? What if we are on a Mac? I presume that building on Mac would produce something that didn’t work on the norns by default
No worries! Just wanted to be sure – compiling on-device is fine. I haven’t had to work in C in quite a few years haha build processes are something I’m pretty happy to have forgotten
The maiden library system is targeted at management of directories under the code directory on device - there are no provisions for dealing with dependencies outside of the normal script directory. The pre-configured catalogs where setup with the intension of helping people share scripts which (in theory) should just work on their devices.
It is possible to define additional catalogs to allow for more targeted sharing. I use this feature myself to help manage my personal scripts across multiple devices - but again this only covers content which live under the code directory.
So I think the ugens can live in dust/code as SC looks at that path when compiling, i just wasnt sure where they should go inside dust/code. Suggestions?
EDIT - FWIW I was unable to get the ugens to be compiled by SC when they are in the dust directory
Totally understand. Just saying itd be nice to have a system where we can distribute scripts bundled with custom UGens as easily as we can distribute scripts (including scripts bundled with Engines). No real opinion on how that’s done, whatever makes the most sense for the platform. Although it sounds like @okyeron is having some success moving the UGens into dust/code post-compile so maybe we are already fine? I haven’t had time to test this all out yet
it should work fine to put compiled .so and associated .sc in e.g. ~/dust/code/foo/lib… it’s not working?
the .so does of course have to be compiled for arm64 and linux. easiest way for me to do this is by compiling on device as said in other thread, but others may prefer to set it up with a cross compiler.
)