Hi all,
Bill Gardner, one of my officemates at the Media Lab, has been
engaging me in a series of discussions about turning SAOL into
a more explicitly "object-oriented" language. I'm interested
in others' thoughts on (a) whether this is a useful direction
to go in from a SAOL composer's perspective, and (b) what the
implications are, if any, for implementations.
Here is the idea: Many opcodes in SAOL have an implicit object-oriented
nature, in that they encapsulate both data about a process and
specification of methods, or functions which influence and query
the process. For example, let's consider "oscil":
aopcode oscil(table t, asig f, ivar loops)
In implementation, this opcode will have some kind of "phase state"
information, so that we can keep track of where the oscillator is.
However, the "methods" offered in SAOL are impoverished with regard
to its state -- the only method is the opcode itself, which is like
"update the phase and return the value of the table at the new
phase point".
An explicit object-oriented version of this would have a constructor
and more methods for referencing and influencing the state. Using
C++ syntax for the moment:
oscil::oscil(table t, ivar loops);
oscil::oscil(table t, asig f, ivar loops); // default method?
asig oscil::run(asig f);
oscil::set_phase(asig ph);
asig oscil::get_phase(asig f);
asig oscil::query(); // get value, don't update phase
Then I could write code which looks like this:
oscil o(t, -1);
asig a,ph;
a = o.run(440);
ph = o.get_phase();
o.set_phase(ph/2);
And so forth.
There are a number of advantages to this scheme:
- it makes it clear that there is an internal state to opcodes
which you might care about sometimes
- it clearly defines *which* oscillation process is being
referred to in which line -- right now, each "oscil()" call
*must* refer to a different oscillation
- further syntax extension might allow you to pass the "o" object
to some other opcode to refer to that oscillation process
there.
- assuming we allow user-defined classes, there will be certain
encapsulation advantages (think of implementing an "acoustic
waveguide package" for SAOL).
There are also a few disadvantages:
- The language becomes ever-larger, harder to implement, harder
to learn.
- Instruments become less and less analogous to "signal flow
networks", as they were in Music V and (less so) in Csound.
- It would be a fair amount of work on the spec and the reference
implementation to get things right.
"Losing the simple oscil syntax" probably isn't a disadvantage, as it
would be easy to keep around as a default.
I'd like to hear comments from other people interested in this
topic.
-- Eric
+-------------------+
| Eric Scheirer | A-7b5 D7b9 | G-7 C7 | Cb C-7b5 F7#9 | Bb | B-7 E7 |
| eds@media.mit.edu | < http://sound.media.mit.edu/~eds >
| 617 253 0112 | A A/G# F#-7 F#-/E | Eb-7b5 D7b5 | Db | C7b5 B7b5 | Bb |
+-------------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:11:09 EDT