In this conversation about developing supercollider plugins for norns, Volker Bohm (@geplanteobsoleszenz) posted his ports of some mutable instruments modules.
I’ve taken that source and re-compiled it on linux (Raspberry Pi) for use with norns and worked on making norns engines.
Note - this is somewhat experimental.
The ugens are a work in progress and may have issues/bugs.
mi-UGens-linux-v.03.tar (980 KB)
(updated May 7, 2020)
On norns the directories in this archive should be installed at
There’s also an installer script I’m testing which you can use to quickly load the Ugens mi-ugens-install.lua (1.8 KB)
remember to restart
once you’ve installed the ugens, SLEEP and restart your norns.
Then I’ve started work on norns engines/libraries with basic functionality here
These are a WIP of clouds, rings, elements and plaits. I’d love to get some other people involved in fleshing these out and for testing/feedback.
Once things are functioning well, I’ll do a script release for the norns Library.
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
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
git clone https://github.com/okyeron/mi-UGens.git
git clone https://github.com/supercollider/supercollider.git
git submodule update --init
# then cd to directory you want to build
mkdir build && cd build
cmake -DSC_PATH=~/supercollider ..
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
NOTE - however I did need to hack/change the
CMakeLists.txt for a couple modules. See here
Nice! Thanks for sharing @okyeron
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
I may be wrong about this location being required. Perhaps @zebra can chime in on where best to install ugens.
AFAIK - There’s not a simple solution for installing ugens just yet.
Apologies - I’ll update that post. This is all on device (Fates in my case).
Unfortunately I don’t know how to cross-compile the linux binaries from MacOS.
It’s stupid quick on device tho.
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
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
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
EDIT - FWIW I was unable to get the ugens to be compiled by SC when they are in the
I get a SUPERCOLLIDER FAIL error after restarting my Fates (latest firmware) after installing the UGens in
NOTE - if you grabbed the ugens archive previously - please get the new version I just uploaded. Top post is updated with link.
Lemme double check back on Fates. I did the most recent compile on Shield. It’s possible they wont work on Fates.
It may also take a reboot (SLEEP+power off/on) cycle to get them working.
Ah, will gets the latest and try them, then.
SUPERCOLLIDER ERROR with the latest, too. Maybe they need recompiling for Fates.
Seems odd though- other SC plugins seems to work across Norns/Shield/Fates (unless they don’t, and it’s just that nobody has tried to use them, yet).
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
Maybe a symlink of the SC extensions directory in /home/we/dust?
Working for me here on pi3-fates with the most recent archive.
EDIT: also no errors on pi4-fates.
Can you DM me with some debug from the maiden SC tab? Wanna try a
;restart and send me the details in DM
Incidentally, the MacOS versions won’t work in Catalina (this is going to happen a lot )
Will have to reinstall them UGens (uninstalled so I could use my Fates).
Gimme a few minutes.
it should work fine to put compiled
.so and associated
.sc in e.g.
~/dust/code/foo/lib… it’s not working?
.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.
I haven’t tried it yet, I was just asking for clarification to the original post which said