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:40 EDT