>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?
How about a GUI that acts as a sort of librarian. Individual saol
instruments could be represented as separate entities, and edited in their
own text window. The user would be able to graphically assemble a saol file
by choosing which instruments to include. All of the global block settings
(srate krate etc) could be edited in a gui, as could the send, route and
schedule operations - you could have a graphical patcher for representing
global busses and routings. Also things like instrument presets could be
assigned graphically rather than in the instrument text editor.
The instrument editor could have some two-way graphical tools, eg you click
on a table() statement and it provides a graphical editor for the specific
generator (for example, a breakpoint editor for linseg and expseg generators
(just a text editor with this feature would be really usefull - hey I might
write one myself when I get some spare time :-)
a java based system would be tasty.
As John suggested, another way to go might be a saol generator that produces
code for a specific class of algorithms (waveguide phisical modelling for
instance) - the user could patch together wave guides graphically and set
their paarameters. The output would be a saol instrument that implements the
waveguide network.
Best,
Ross.
>> 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