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.
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).
