Hello it’s been a fun few days of playing around with fates
I was wondering if someone could explain to me how to install a patch from patch storage
I tried with the tools I have vaguely acquired
But can’t seem to figure it out
Hello it’s been a fun few days of playing around with fates
Pure Data users may interest this
Can’t seem to get midi note information into ORAC, I tried akai mpkmini, OP1 and OPZ, tested every channel and still nothing happens. Would be great to have a list of compatible controllers listed in this thread. What should i do to make them work?
Also how do you guys adjust the output level of the patch?
Is there a way to run Supercollider on the Orac side?
I want to copy/paste code from the computer version and play it on Norns, bypassing the Lua/Engine setup of the regular Norns.
Ideally I want to type code directly to Norns via a keyboard to some sort of front end black screen emulator.
you don’t need orac or anyhting to do this, you can use the sclang instance that already runs on vanilla norns.
i’ll share a simple engine that executes arbitrary .scd files.
heck, you could even make a norns script with a pipe to the sclang process
If that avoids having to make a separate script / engine for every patch, then great. Basically something playable and instant, akin to Teletype, but Supercollider. A keyboard, Norns and a black screen to type Supercolier code, that works exactly the same as writing the same code on a computer.
The reason I was asking was because of that Norns Mother thread. Norns Mother (Organelle Patches on Norns)
That script in Orac has opened up Norns to Puredata / Organelle patches like no other. For me personally, it plays Automatonism pd patches which are far more advanced/developed than the r engine equivalent on the vanilla Norns side, for example. Even the more experimental pd offerings from Martin Brinkman worked Norns Mother (Organelle Patches on Norns)
I saw that Supercollider runs on Orac / Organelle so that was the reason for asking. I thought maybe easier to go the Orac side to get done. But I honestly don’t know because I’m not a coder.
no you don’t have to do this. a wrapper engine is trivial and i will share it later. norns engines are in a special format so you can control them from lua. if you don’t care about this you don’t need to use the engine classes.
you can also pretty trivially launch another audio process from a script
init, and kill it from
cleanup. i actually use norns for this pretty frequently, because i find the lua layer a very convenient way to make app launchers and manage configurations in the same manner as sidekick’s .json file.
perhaps some details on this might be useful…
so prior to Organelle OS 4.0 it did not have supercollider installed,
so I figured out how to get supercollider working on it, and packaged it up.
I also integrated supercollider with the ‘mother host’ which is responsible for interacting with the screen/pots/encoder of the organelle.
(this is now all part of OS 4.0 , so works out of the box on the Organelle)
so… norns/fates doesn’t need this, as supercollider is already installed.
so the only question is interaction with the hardware (encoders/buttons/screen)
as @zebra says, you already have this by using norns, and using lua.
(all hardware interaction is done in matron so part of the lua layer)
but this does raise another possibility that ive been considering for a while,
currently to interact with the hardware you have to use the NuiLite api, which is C++.
but the idea is that Id extend sidekick would allow interaction with the hardware via osc messages… so any ‘programming language/app’ that can send/receive osc, could be used… this would not only work for supercollider/sclang, but would also open things up for those wanting to use things like python.
(funny thing is… this actually means sidekick is just becoming more like mother host on the organelle … which I guess is no big surprise really ;))
no promises, but I do want to return to look/extend nuilite with more graphics primitives anyway, so perhaps whilst doing that, I’ll take a look at adding osc support to sidekick.
Thanks for the info, I didn’t know the full background for Supercollider on Orac or the issues with hardware interaction. I would want some minimal control, even if it’s just being able to assign 4 knobs/buttons on a Norns but ideally some sort of midi/osc controller/grid
Ive started work on adding OSC support to sidekick, and more graphics too…
the idea is sclang, python, shell scripts will all be able to then access the hardware … so get encoder and button events, draw to the screen.
all that said, there is still the ‘other part’ of your request…
from what I gathered you want to be able to have a ‘terminal like’ console on the norns screen - correct?
I have to say I’m not sure about that…
I think fundamentally the screen is too small on the norns/fats to really be ‘comfortable’ for that…
I guess typing in a few sclang commands (eg Ndef, Pdf) for live coding you might get away with it,
but if you type something wrong, then you need to see error messages… and this are VERY verbose on supercollider - even on a computer screen! … hard to know how you’d deal with that.
similarly you quickly start needing to be able to recall other lines, edit them…
and before you know it that simple terminal application could get quite complex.
Yes, that’s what I mean’t but if the limitations of that screen make it not possible / suitable then I understand. I thought you would be able to scroll left / right. The thought behind it was to have something portable and not having to have a laptop to live code, just a keyboard. If that’s not possible then the alternative is not to livecode, and make your patch on a computer and drag and drop that onto Norns which seems the most viable, which would be great also. It would still be a minimal setup with no computer keyboard / or laptop screen.
What I’m interesting in specifically are making self generating patches were you can steer them in certain directions with minimal control, a few knobs, no piano keyboard, a small controller with sliders.
yeah… its an interesting area, is it worth ‘replacing a laptop’…
I admit, Im more cautious recently, as a few times Ive spent significant effort getting things to run on a rPI partly to be ‘dawless’, and partly ‘because I can’…
and Ive looked back, and thought… why not just run this on my laptop? so these days I try to challenge myself (before investing too much effort into a project)
not sure I get it right, and I keep experimenting e.g. the other day, I got a tracker running on my organelle, with a 7" screen and mini keyboard… sure, its cute, its fun… but is it actually any more practical than using my laptop with Renoise (which is a much more ‘powerful’ setup)
at the moment, the two ways I found I get value out of these devices is:
a) standalone - running patches (be it supercollider, or pure data)
Organelle, I love for this, as its got a (albeit primitive) keyboard, so its complete, can be used anywhere.
Eurorack modules (Bela Salt, Nebulae) , acting as standalone modules
b) live coding (& patch development) (supercollider)
Eurorack modules… (Bela, Nebulae) so here I connect a laptop, which runs supercollider IDE.
the reason, Im using the modules in this case is because they are ‘interfacing modules’
this way I get a decent screen/keyboard, but I’m ‘integrated’ into the eurorack world, with both audio and cv patching.
I really love this setup… its comfortable but still has the hands on control.
(of course, I could use the laptop + ES8, but this lacks the hands on control at the eurorack end)
unfortunately for me (perhaps because I don’t have a grid?) , my Norns (Fates) tends to fall between the gaps, so it’s not getting used much… if I want portable I grab the Organelle, otherwise Im a bit Eurorack obsessed at the moment
that said, the reason Im going to add OSC support to sidekick, and so get sclang working, is perhaps then Id write standalone SC patches for norns. (as you mentioned)
what I can do then, is like Im doing on the Nebulae now, is use a nice combo of laptop + norns for development.
what I do on the Nebulae for development/live coding is… (and so would do on norns)
have Nebulae running the server, and proxying the osc messages to sc-ide running on my laptop.
so I can do all the dev on a decent screen/keyboard, but in a way that I can literally just copy the develop SC patch over to the Nebulae and then it runs standalone (without laptop) on Nebulae.
its a really fun way to develop…
Im hoping if I do this for Norns, because it’ll be similar to what im doing on the Nebulae (and Organelle), I’ll get some synergy and be able to transfer patches across to norns without specifically having to develop for it… so hopefully my norns will get a little less dusty
Is there an installation method that will work for a norns shield?
sorry, I dont have a norns shield, so cannot say… is it the same as the normal norns?
if so just follow the install instructions and will work.
@okyeron - are there any differences in shield that will stop this working?
(my guess is it should work…unless there are some packages missing?!)
In other news 0.2.0 is released…
if you have sidekick already installed, ‘Check for Updates’ will install it,
if you don’t (why not?) then just follow install as per top post.
Next post will contain details of whats new … and its quite a bit
Sidekick 0.2.0 Release
upgrade with ‘Check for Updates’ in sidekick menu
or install as per top post
note: this will overwrite your existing sidekick folder,
if you have patches already installed, I recommend you back them up beforehand!
p.s please do just copy, old versions of system files back once installed (e.g. sidekick.json) , as there are new settings in this file.
Sub directories for patches
this not only allows more organisation,
but also more ‘isolation’ the parent directory can contain contain pre/post scripts, and things like pd-opts.txt, so groups of patches that need similar setup can use these without ‘polluting’ other patches.
Extended graphics api in NuiApi
rectangles, circles, setpixel, filled areas… lots to explore
available using nuilite api, pure data or osc (see below)
Sidekick now sends and receives OSC messages…
this enables you to write applications in any language with OSC support to do things like:
– ‘paint’ to the norns display
– receive encoder/button events
– send/receive other sidekick events
– use ‘vanilla’ supercollider
– launch supercollider patches (scd) directly from Sidekick
– support for drawing to display, receiving encoder/button events etc. (via osc)
– live-coding support using the SC IDE on your desktop/laptop
– does not affect Norns use at all (see below)
The demo patches are now installed by default, there are demos for pure data and supercollider.
New OSC/PD Messages
Ive listed the new messages in the default supercollider patch
Supercollider & demo patches
supercollider home is : ~/sidekick,
if you want to update the startup.scd its in ~/sidekick/.config/Supercollider/startup.scd
doing so will NOT affect Norns
a template to get you started, showing messages
launches a simple synth, shows how to use display and control it via encoders
this is a template showing how to enable ‘live coding’ on norns
simple granuar demo, again showing how to interface with norns hardware and load sound files
you are free to delete the demo patches, or move them around
(though, id keep them handy … in case you want them later esp default/live coding)
Supercollider live coding patch
This patch can actually be used for 3 purposes,
a) live coding
use the supercollider IDE on your desktop/laptop, using the Norns as a remote sound engine.
you have the ability from your desktop to paint to the norns display, and get all the events from the encoders/buttons into sclang … so great for using with Pdef etc.
this is really just a variation of (a),
since the messages that are sent by the live coding patch, are the same as the sidekick (it just adds as a proxy) - you can develop patches on your desktop that are run on your norns, and then just copy them to your norns to run standalone!
(really efficient and easy to use workflow!)
c) as a template for adding to your own instruments for remote control
so the live-coding aspect, is a SC patch - demonstrating how to proxy messages onto to remote client,
you can this as example of how to allow your own patches to be controlled remotely.
reminder about sclang / scsynth
its worth remembering what is sclang code and server side
when running a patch from sidekick, we are launching both sclang and scsynth.
so you can have all the fun of client language support (PDef ) and server side.
when using things like midi remember this is client side,
so when you run a scd patch on Norns, it’ll get midi from devices connected to Norns.
if you move to live-coding, then the sclang midi code you run on your desktop, is going to talk to midi devices connected to your desktop.
this is fun, you can construct patches where you use midi controllers connect to both norns and your laptop !
If you want Supercollider, why not just use Norns ?
its an obvious question… the answer is simple - if thats what you want, then go-ahead,
Im providing choice , no more , no less!
personally, I wanted a more ‘vanilla’ experience, since I’m developing on other platforms,
so I want to use sclang rather than lua, and for my purposes I don’t need things like softcut/crone.
this is no slight on norns, its a personal choice… which I offer to others if they are interested
you are free to use what you want!
you can use Norns, you can use Sidekick supercolider or both (they do not interfere with each other)
This is fantastic thanks once again.
am getting this error when trying to vnc to my pc:-
using framebuffer /dev/fb0
terminate called after throwing an instance of ‘std::runtime_error’
what(): unable to bind udp socket
most likely you are running 2 instances of sidekick.
are you trying to start sidekick from the command line?
if so, did you stop the sidekick service?
(sudo systemctl stop sidekick)
other than that, its like something is using port 3000/3001?
one I forgot to mention, but very useful
Ive introduced a lot more ‘hook points’, which are optional scripts that can be used to change how things behave… these are like the old post-patch.sh script but a bit more powerful.
they cover things like, PD options, supercolider options, what to do when patches start and stop.
here is a ‘real world example’ I use
using supercollider with an alternative audio interface (ES-8)
I use norns connected to my modular via an ES-8 audio interface.
so by default, sidekick when start a supercollider patch, also starts the ‘norns jackd’ service, to get jack running. it does this with a script called ‘start_sc.sh’ (and a stop corresponding stop one)
now I don’t want to edit the norns jack service, as I dont want to affect norns behaviour.
so instead I can edit start_sc.sh to launch jackd itself, with new parameters to utilise the ES-8
ok, but that means every SC patch on Sidekick would now use the ES-8,
I want it more selective
so I put start_sc.sh, into a patch directory - low and behold, it will be used only with that patch. so I can default to normal output, and only that patch will use the ES-8.
nice, but inconvenient if you have a few patches…
so, there is another level, sub directories.
I can create a subdirectory for patches called (e.g.) Eurorack, then put my patches in there.
then put the start_sc.sh in the Eurorack folder, now anytime a (sc) patch in that folder is invoked it will be connected to the ES8, but other SC patches will be unaffectd.
(and yes for ‘linux’ heads, you can use symbolic links, so you dont need to even duplicate patches :))
basically hook files, like this work on the principle of…
use file in patch directory , or its parent directory, or the main sidekick folder (aka global)
btw: to do a similar thing with Pure Data , you just need to add a pd-opts.txt file, again hierarchy is respected.
of course, this means that your ‘Eurorack’ folder can now be a mix of Supercollider and Pure data patches
Use the details tag on discourse - we really don’t want code to disrupt this thread
No idea about compilation issue, often it’s compiler version - it’s whilst compiling oscpack which is an open source lib I use on lots of my projects, on lots of platforms so bit surprised it’s not compiling for you.
Are you sure it’s not just a warning?
Why are you recompiling? that’s a complexity we should try to avoid
sorry yes its as i have a 320x240 screen on my diy rpi norns, all i changed was 128 to 320, 64 to 240 at the beginning of the script and added a scaling factor like this:
cairo_scale(cr_, 2.5, 2.5);
on line 640 in NuiDevice.cpp