Subject: Re: [linux-audio-dev] What I want, to stop using Windows
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Sep 28 2000 - 03:55:20 EEST
>Let's take Paul's judgement of SAOL vs Quasimodo as a sound language
>as fact for a moment -- I have my own opinions, but its irrelevant to
It may seem like a minor quibble, but its really important to
understand that Quasimodo is *NOT* a sound language. Quasimodo
dynamically loads the parsers+compilers for the sound languages used
by the modules it runs, and does not contain *any* built-in language
of any kind. A module, once compiled, is expected to provide an
"execute()" function much like the VST "process() one, and an
"initialize()" function (*). All Quasimodo does is to call these
functions. For all I care, these might do:
system ("perl -e \"some perl code that does something\"");
This is *really* important to me: Quasimodo is intended to be language
neutral. Its main design goal is in providing both a real-time,
multi-threaded skeleton in which to execute modules regardless of
their definition language, and in the case of a front end like
gtk-quasimodo, a GUI with which to easily manipulate a play with the
parameters and routing/interconnections between modules.
I just took a look at the SAOG site, and SAINT seems quite interesting
(it also bears a remarkable and no doubt entirely non-coincidental
resemblance to the internals of Quasimodo - i say this not because i
am suggesting any copying, but that anyone who thinks hard about how
to take a Music N inspired language and implement it efficiently will
come up with a similar scheme). If someone, even me, was to write a
SAOL language module for Quasimodo, it would be excellent. I have even
talked about doing this in the past, but I now prefer going down the
C++ route as the new/next module language.
(*) it also has to provide a few other things too, such as a
set_parameter() function, but you get the point.
>But on the other hand, there are lots of other systems where the
>installed base of MP3 as a standard overwhelms efficiency gains you'd
>get by moving to a technically superior format.
This is true, without a doubt. What's sad for me here is that MP3 is
not a programming language, and when MP4-SA is used in the vast
majority of the systems where it will be deployed, it will also not
really be a programming language in the sense that no human will sit
down and express algorithms with it.
The reason why I don't like SAOL for this purpose (expressing audio
generation and processing algorithms) is that the language has a
number of artifacts that arise from its heritage. Its sort of like
someone having decided to use, oh I don't know, cobol as a new
portable way to distributing some information. its not that it doesn't
work, or even that it doesn't work well. but it (SAOL) doesn't
represent the accumulated knowledge we have about programming
languages, and instead represents (to me) an incremental step in the
Music N tradition.
Once an MP4-SA "thing" (instrument) exists, its fine. What I don't
like is the idea of trying to express new algorithms, new processing
structures, etc. in a language that is weak on control structures,
strong on variable typing, and rigid about certain implementation
models. I wouldn't like it if the MPEG group had picked perl for this,
or cobol, or basic, or apl, for that matter.
--p
This archive was generated by hypermail 2b28 : Thu Sep 28 2000 - 04:16:06 EEST