Let's talk about running your patches on different hardware - and how open or closed system is the Norns?

KristofferLislegaard · 2021-06-14T21:13:38.188Z

Ok so one thing I have been thinking about is that if I spent a lot of time making patches / scripts / systems / whatever and using those as my instruments, it would be great if those patches could run or be easily adapted to run on different hardware.

I have been making some cool stuff in Max but it does mean that I need a Apple or Windows computer to run them. While that is not too bad I love have something more like dedicated sound computers. Things like the Norns . Organelle , Pisound , ER-301 are so nice! But it would be nice if that sound computer could run something that could also travel easily to different hardware if necessary.

One example would be Pure data . It runs on Macs, Windows, Linux, Intel, ARM , you name it. This makes it really easy to make a patch and choose the hardware after. If f.ex. I plan on playing a concert with my Organelle-M or a Pisound and have made patches for those in PD , if my device broke (let’s say on tour) it would be pretty easy to adjust my patch to work on my (or a borrowed) macbook pro or something. This is a really nice thing, because it basicly means that whatever happens to the companies that makes the hardware I am using, or if something brakes and I don’t have time to get a new one, my time spent making my instruments are not wasted, or my instruments are not lost.

Csound also seems great. It seems to be able to run on basicly anything and can even export to a VST via Cabbage .

How is the Norns in this aspect? I would love to get either a Norns or a Norns shield , and I am happy to learn how to code my own patches for it, but I am a bit scared if it is too locked in? This is after all one of the reasons why I am looking outside of the tools I have been mostly using until now (Apple computers running Ableton Live, Max and Max for Live). Also one of the things I have always love about Monome is the community around it. And I love my grids! This is a big plus for the Norns ! But if I spend a lot of time making instruments for Norns how easily could they travel to different hardware if nesseseary?

I guess this topic is a combination of a discussion around the topic, but also asking a bit about how this is in the Norns .

THÆNKS!

toneburst · 2021-06-14T21:27:37.687Z

Norns patches are written in the language lua, and audio is generated by SuperCollider patches.

Both Lua and SuperCollider are cross-platform and free, but the subsystems that link them together in Norns may not port easily to other systems, especially non-Unix-based ones.

If you’re interested in cross-platform, pd-based systems, you might want to check out ORAC. That can run on top of Norns, on the Organelle, and on some other systems, too.

glia · 2021-06-14T22:39:02.175Z

KristofferLislegaard:

If f.ex. I plan on playing a concert with my Organelle-M or a Pisound and have made patches for those in PD , if my device broke (let’s say on tour) it would be pretty easy to adjust my patch to work on my (or a borrowed) macbook pro or something.

Well the first thing to note is that in essence Norns is similar enough to Organelle that you can absolutely run vanilla Pd patches, Organelle, and Automatonism patches on norns.

Similarly, you can run supercollider on the platform…but again, i’d say it’s possible if you desire that functionality but not designed for that as the main use case.

KristofferLislegaard:

How is the Norns in this aspect?

One example came to mind 1st…less concepts is a cell auto sequencer that started with experiments on teletype, then max, then max4live, then norns, then briefly a crow standalone version

it’s been ported and reworked many times to fit various systems and the updated app is available for norns and m4l

Unlike teletype, though, norns uses two common languages for nearly every task in the standard operation of the device: supercollider and lua. Some apps only require lua

that’s what makes it possible to transfer cross-platform to anything that can run SC or lua

I still wouldn’t say it’s always easy to do but with effort (especially if you design your app to be agnostic from the get go) it can be done

andrew · 2021-06-15T00:04:44.161Z

as-is it seems like supercollider would give you what you’re after - all your music logic & sounds can be written in an SC class that would be fully cross-platform (w/o modification) and your lua code can just be a dead-simple script that defines a simple interface via the params system or otherwise.

most folks in the norns-zone choose to do a lot of the business in lua, but for most stuff (audio & musical events) you don’t have to

KristofferLislegaard:

whatever happens to the companies that makes the hardware I am using, or if something brakes and I don’t have time to get a new one, my time spent making my instruments are not wasted, or my instruments are not lost.

oh & fwiw norns shield is open source hardware & monome is great about servicing things, so i’m not sure there’s too much to worry about in these regards specifically ! but i get that for certain things portability is handy

eigen · 2021-06-15T04:44:21.879Z

If I understand correctly, there are plans to make norns’ software run on a regular computer. No patching to norns scripts would be needed.

The limiting factor is how tightly coupled current iteration of norns’ source code is to the hardware screen, but considerable effort has already been made to get out of it.

Still, the aim is too keep norns scripts being able to run on any of the hardware version of norns, with its limited resources (3rd gen raspberry pi).

Having a computer application may give users the illusion of way higher resource thresholds (CPU / RAM). If scripts get developed to only run on beefy computers, this might divide the community.

That’s were most of the challenge seems to lies in.

toneburst · 2021-06-15T08:04:48.153Z

It should be mentioned that, while Norns scripts are written in lua, they do make use of the Norns API to interface with the hardware and make sounds, so simply running the scripts on some other platform won’t work.

infovore · 2021-06-15T11:37:47.641Z

I tend to find that most discussions around a one-dimensional axis (“open or closed”) tend to inevitably involve more layers of complexity. I think there’s a two-by-two matrix at work here: open/closed vs tightly coupled/loosely coupled.

So for instance: Organelle is quite open, and also somewhat loosely coupled: you can write for it in pd, but also relatively easily port existing pd scripts onto it, taking advantage of its UI and IO. It isn’t a huge deviation from ordinary pd.

Norns is quite open, in the sense that you can write your own things for it, and not just UI-based scripts (assembling existing engines) in Lua, but also new Supercollider engines… but it’s also quite tightly coupled: it’s not just “Lua+Supercollider”, it’s “Lua+Supercollider with a number of key, immutable preconceptions about how everything is connected, as well as the maiden/matron/crone infrastructure.” This is not the same as a greybox running Supercollider.

Sometimes it’s easy to confuse open for loosely coupled, but one doesn’t necessarily presume the other. And sometimes people say they appreciate open things, when really, they appreciate loose coupling. (Personally, as usual, it depends on the circumstance for what I like. There are lots of advantages to the tight coupling of Norns - ease of installation of other people’s code, easy of working with other people’s code, ease of learning a constrained system).

There’s a reductio ad absurdam argument that it’s easy to get into that suggests that tight coupling is the road to hell, and the only way to avoid it is to use entirely open and loosely coupled platforms that you are more free within; this tends to descend into “only work with stuff you’ve designed and implemented yourself”. At which point, I say, “how far down that hole are you willing to descend?” because you know, are you willing to bet on that build of Ubuntu remaining solid for as long as, say, a decent guitar? (The answer may be yes, or I don’t care). Usually, though, this is a good way of exposing the boundaries of values, rather than suggesting they are incorrect.

KristofferLislegaard:

This is a really nice thing, because it basicly means that whatever happens to the companies that makes the hardware I am using, or if something brakes and I don’t have time to get a new one, my time spent making my instruments are not wasted, or my instruments are not lost.

True. But entropy comes for us all; witness people trying to keep Nord Modular editors alive, for instance.

Another way to think about openness and coupling is openness of knowledge. In general, I have rewritten a lot of code in my lifetime - I’m always returning to old patterns, implemented in new languages or systems. And now I know them, I am fluent in them: it is not *really *a chore to knock out something I know how to do in a new language.

To that end: if, say, this platform is a dead-end, but the things I learned implemented it are easily ported, then I don’t think it’s a huge dead-end. For instance: porting one curly-brace-ish language to another; moving a Supercollider engine from Norns to a standalone system (and replacing some of the Nornsisms). But if the thing you’ve learned to do is a dead end - everybody else does it differently, you’d be starting from scratch if this thing ever died… that feels like more of a risk than literally not being able to just drag my code onto a new piece of hardware. Again, personal preference. (And one issue I have with Max: it’s a great platform, and it’s also not just tightly coupled, but quite unlike many alternatives, to the extent a ground-up rewrite might be painful).

mheton · 2021-06-15T11:41:50.486Z

very good analysis and thoughts

KristofferLislegaard · 2021-06-17T16:00:54.820Z

Thanks to everyone (special thanks to infovore) for all the great thoughts! Lots of things to think about here!

If anyone else wants to chime in about their favorite programming languages (and why) that is very welcome as well.