Hello,
1/
The OOP opcode syntax seems more long winded than the original
syntax.
How about modifying just the table and file representations to
be object oriented.
By replacing the file io and table sections with a streams based
interface. Here a signal could be read from ram or disk
etc with one interface.
// Create a file mapping -
file sin_table(wav, "sine.wav")
// Or create a ram based mapping -
table sin_table(harm, 4096, 1)
// One syntax fits all -
sin_table.write kposition, ksig
// Function syntax
ksig = sin_table.read(kposition)
// All sorts of operations would be possible
sin_table.invert
This way the unifying nature of the two storage mediums becomes
more apparent. You can design for ram but then use disk if your
files get too long. Just change the declaration.
2/
How could the standard support scores running at different
sample and control rates? Could support be provided or is it
already? Issues include how to pass timing/signals between
scores.
This would be useful for minimizing computational load and
enabling different source rates to be combined eg dat/cd.
3/
Video processing is a must for this sort of architecture.
Special effects of real detail and quality and control.
How to do it best is wide open but i feel it has to be allowed
in somehow. (Or at least not prevented.) I favour the OOP model
for this certainly possibly as an extension to the table
metaphor.
table faces(jpg, "c:\pics\face.jpg", ksig)
If ksig = 15 then it would load "...face0015.jpg".
Then manipulate using opcodes.
scaleimage faces, kxsize, kysize
rotateimage faces, kangle
compositeimage faces, 100,100, background, 10,10
and so on...
As an animator i know of nothing that could approach the
event/signal architecture for certain tasks.
4/
A socket based interface to the api to allow a client to access
SAOL as a server. Rendering using my network at work sounds more
fun than using my P120. Should go like a Cray if you work in a
office block with a friendly Sysop :)
5/
Dynamic linking of opcodes would be useful and some form of versioning
and opcode registering (so that we don't all call our
opcodes reverb3) would be handy. This would allow the language
to grow gracefully over the years.
Probably most of these ideas should be for later versions.
I feel you should try to get Mpeg-4 out as soon as possible
so that people can experiment and enjoy programmable synth design.
Once they have tried it - they will want more...
Congratulations on such a fine first release. It compiled first time -
something few programs seem to do for me.
Bye,
Mike Chapman
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:11:09 EDT