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