Hi,
It is an exciting time for programmable synthesis at the moment. I think the
standard will
go a long way to making digital synthesisers as experimental and fun as an
analog studio but
with all the control possiblities blown out of proportion. Is any of this
available for an
eager tester? You talked about the possibility of a java or c++ version. Is
any source going
to be made available? that would be great! Could anyone explain the
licensing issues. Am
i right in thinking that anyone can develop commercial / free products based
on SAOL?
Just a few little questions/thoughts/comments-
1. Would it be possible to include support for arbitrary sample rates to
communicate eg.
sr = 25 and kr = 25 video rate control info for
sr = 1000 and kr = 25 analog control of mixer info
sr = 44100 and kr = 1024 for audio or disk I/O buffers
2. Would it be possible to allow more than one version of the scripting
language for future
syntax enhancements? If the language is to have a very long life (like
MIDI has) it may be
nice to allow many languages to use the same stream and score formats? A
possible enhancement
may be a more oop format for variable names?
> * having the language standardized independantly from any particular
> implementation means improvements and new implementations can
> aim at a fixed target
Eg. Mixer.Route Soundcard.InputL, Disk4.Channel4
or
asig = DrumFile.Read(iPos, iChannel)
3. I also feel there should be some base level of standardised
error/debug/trace for
SAOL orchestras.
>>9. Debugging this language will be difficult, especially when the programs
>>are complex, and the implementation is not bug-free. I propose a
>>"log_msg(<string const>)" statement that can output a string, and a
>>"log_num(<expr>)" which can log a real or integer number to a logging
>>device, which can be implementation dependent, such as the console, or a
>>log file; but may be different from the device used to log syntax errors.
>I'd say these are implementation issues -- nothing is preventing you,
>as implementor, from adding "extra" non-portable opcodes, and these
>obviously only apply to developer-composer oriented implementations. If I
>want a playback-only box to run as fast as possible, I want stuff like this
>out of it.
Perhaps it may be possible to fall into c's problem of not going far
enough to specify default functionality for important functions.
4. How will it handle syncronisation to MIDI timecode or other
processors/threads?
5. Will it be case insensitive? ! please do!
Overall - it looks like you have done an excellent job.
I hope it all takes off soon. MIDI has held experimental synthesiser design
back for far too long...
Mike
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:11:08 EDT