I think a realtime decoder is beyond the scope of your project - more work
than you think, unless you are a compiler genius. Or did you mean wrapping
up sfront as a FreeAmp plugin, which would be quite easy? But then it would
still require a C compiler... SAOLC is not fast enough for a realtime
decoder.
I think John is right that a GUI patcher would enable many people who
already have used Generator and such to quickly become productive in SAOL,
and I agree with you that Java is the best choice of language; entirely
capable of producing the application and having it perform well.
Furthermore, if you do your work well, it will still be useful long after
realtime decoders have appeared, precisely because the language itself is
standardized.
-----Original Message-----
From: Michael Gogins [mailto:gogins@nyc.pipeline.com]
Sent: Tuesday, October 26, 1999 7:33 AM
To: Bert Schiettecatte; John Lazzaro
Cc: saol-dev@media.mit.edu
Subject: RE: Intro...
Visual patch editor (boxes with wires that you pick up from a palette and
drop onto a form), as in Generator/Reaktor, Syd, AudioMulch, aRTs, and
countless other programs. There was one for Csound from Russell Pinkston
called Patchwork that no longer seems to be supported. A GOOD one would be
QUITE useful and, in fact, necessary for SAOL to compete in the popular
music market.
-----Original Message-----
From: Bert Schiettecatte [mailto:bschiett@vub.ac.be]
Sent: Tuesday, October 26, 1999 3:52 AM
To: John Lazzaro
Cc: saol-dev@media.mit.edu
Subject: Re: Intro...
Hi,
> I'd suggest considering writing programs in SAOL, rather than
> writing SAOL encoders/decoder tools, as a project -- be it an instrument
> and effects library, or even better a generator system, that generated
> SAOL code from a higher-level language or a GUI (for example, a Web
I guess it'll have to be a GUI that generates SAOL code. But since SAOL is
such an open language in which you can program new instruments, how can a
GUI provide a very high-level way of specifying instruments?
> These sorts of projects (especially the generator-type projects)
> would result in a large base of SAOL code being built up quickly, which
> the people working on decoders can then use to test/optimize their
decoders.
> In addition, it gives musicians instruments which they can use.
Indeed. I will probably develop the program in Java then, if I do it. In
that way, it can run on any platform and I don't have to worry about
portability of my GUI.
The other idea I had was making a real-time decoder, but make it a plugin
for FreeAmp (www.freeamp.org). I would use some of the SAOLC code for that
since I'm not a mathematician :).
Our assistants REQUIRE that we write in C++, Java or SmallTalk, and that
we have to 'design' at least a bit on our project. We need to use UML, use
cases, design patterns etc ...
But if I base my code on SAOLC and use the FreeAmp plugin architecture, do
I actually have any freedom to 'design' a new internal architecture for my
decoder?
Thanks for any other suggestions,
Bert.
__________________________________________________
Bert Schiettecatte bschiett@vub.ac.be
1e lic INF Vrije Universiteit Brussel
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:41 EDT