One of the things that I like to say about programming is that all programming reduces to three questions:
- What information do I have? (Arrays that have been manipulated by a genetic algorithm.)
- What information do I want? (A SynthDef.)
- What operations will transform #1 into #2?
Particularly #3 is not a trivial question (and this is usually an iterative process) – but it all comes down to this.
One catch in this specific case is: If there should be a deterministic relationship between 1 and 2, then 1 needs to be unambiguous.
- OK: Input A → Output Z, and Input B → Output Z. (In SC,
rrand(1, 5)and1 rrand: 5are different inputs but compile to the same result.) - Not OK: Input A → Output Y and Input A → Output Z.
You might run into problems with the input design that you posted.
It looks like a kind of FORTH style reverse Polish notation – and if they’re already separated into items like this, then the parsing is finished. (Parsing = converting a flat code string into a data structure of tokens – but you already have the tokens.) It would be fairly easy to create a stack and then let the opcodes manipulate the stack:
- Push 2
- Push 0.1
- Push 440
- SinOsc pulls 440 and pushes the UGen instance.
*pulls the SinOsc instance and 0.1 and pushes the*result.- etc.
That wouldn’t necessarily give you a code string, but it would give you the UGen graph as a resulting data structure. (Or perhaps the "push"es are all strings.)
BUT: To be unambiguous, you can’t skip arguments.
SinOsc takes two arguments: frequency and phase. In that data structure, how do you know that 0.1 is not the SinOsc phase? Currently, there’s no information to disambiguate. That is: Input A [0.1, 440, "SinOscAr"] may correspond to Output Y SinOsc.ar(440) with a residual of 0.1 to be used in a later operation, or to Output Z SinOsc.ar(440, 0.1). That’s exactly a situation that’s disallowed in compiler design.
So the data structure may need some revision.
hjh