I’m not “back” permanently – just that this is a topic I’ve taken a lot of time on, and my views on it are different from what’s been discussed so far.
The gist of this thread seems to be methods for organizing global variables.
My approach is to reduce global variables, and instead, as much as possible, encapsulate into self-contained “musical process” objects.
Let’s say you want to use a pattern to play from a sample file, onto a bus.
The usual way that we model this in SC is to load the Buffer into a global variable, and allocate a Bus object into a global variable, and then reference these in the pattern.
Around 2004-2005, I noticed (after wasting tons of time preparing a piece with an awkwardly interconnected object design) that the compositionally significant level of organization is not the pattern (necessitating outside management). The pattern with its resources represents a sonic layer or musical process.
What if I could instantiate the process as one object, and get an object that is fully responsible for all of its own dependencies (and only its own dependencies)?
The other problem at that time was that it wasted a lot of time to have to recompile the class library, reboot the server, reload everything just for a minor change. So I wanted to be able to make changes to a specific process definition and reload it on the fly, and replace only the affected process objects. This ruled out classes – rdd propoosed otherwise, but I still feel very strongly that the class library should be for common elements only; definitions specific to a piece or performance should be “soft.”
Step 1, then, was the ddwProto quark. Prototype-based programming can be used in a way very similar to object-oriented modeling. You get encapsulation, polymorphism, inheritance, but not hardcoded into the class library.
Step 2 was global storage. PR(\name) is a process prototype, analogous to a class. At that time I was interested in abusing the ChucK operator => for double dispatch, so, to instantiate a process, you “chuck” it into a Bound-Process BP(\name) (which “binds” the prototype to specific data – the nomenclature… well… lacks poetry but eh, there it is – btw there is nothing inherently necessary about “chucking” – it wouldn’t be hard to define alternate methods if you don’t like that syntax). The prototype defines constructor and destructor methods to prepare everything that’s needed for the pattern (which is defined in an asPattern method). Like Pdef, you play/stop etc the BP() directly.
In my performance setup, there are a few MixerChannels created globally, in the topEnvironment – but only these. No extra buses, no buffers, just the minimal mixing framework (hwOut, master, couple of reverb FX channels). Everything else belongs to a BP. So the surface area of what I have to manage by hand is extremely small. After that, if I need a hi-hat, I just instantiate the process and the BP goes and gets the sample files for me, no fuss, no globals, no namespace collision, and I get automatic cleanup if I do BP(\hh).free. Instead of a complex process of loading a large number of resources up front, I load resources incrementally, and each process’s own initialization is relatively simple.
Targets in the OP are interesting, but if I wanted to have different studio arrangements, I could create a process prototype for the global mixers, with different configurations. (There’s no rule that a PR/BP must be a playing entity.) Or, if I wanted a global buffer pool, I’d write a PR for that too – because it’s (pseudo-)object modeling, you can do anything.
It occurs to me that this is approaching the problem from the opposite direction – rather than a top-down organization of resources, this is bottom-up – letting individual components manage themselves.
This design has not needed significant revision since 2005 (17 years), so at this point, I’m confident that it’s a successful approach.
BTW all of this is discussed in my SC Book chapter.
sigh back to job job…
hjh