Tolve and Fred Floberg write:
>> will csound ultimately be crushed by commercial programs that do offer
such
>> an architecture?
>
>I think Csound has a large enough user base distributed across so many
platforms
>that it'll be hard for a commercial product to crush it simply by offering
a
>plug-in architecture, IMHO. Besides, if a product were to come out that
rivalled
>Csound with plug-in support, code could possibly be written for Csound to
use
>those plug-ins (assuming that they had some advantage over Csound's
opcodes)
>just as GIMP has done with the APS modules.



A little while ago I made a proposal on the music-dsp list for a "common"
synthesis
plugin standard be developed - this would be one that was suitable for use
with
any number of systems (a bit like midi) not just specific to one program (as
atleast
on the PC there are already a number of incompatible proprietary plugin
formats).

The idea is that users would benefit from being able to choose which "shell"
they
hosted their plugins in rather than their being any war between shell
developers and
vendors.

Following my initial proposal (and moderate interest from people who didn't
see
the idea of a generic standard as a commercial threat) I did some more
research into
the idea of cross platform "components" ("components" being the appropriate
cs term for common plugins)...

I read the book "Component Software: Beyond Object Oriented Programming"
by Clemens Szyperski (adison-wesley 1997) which is an excellent introduction
to
the current state-of-the-art. It seems to me that some of the issues
(positive and
negative) are:

1. If a component architecture was introduced it would be logical to have
most if
not all opcodes split out into separate "plugins". Given the current
development style
of Csound, integration of new units is  easy anyway, without a need for a
component
architecture.

2. Debugging signal processing plugins requires some kind of "test-harness",
which on many platforms still makes debugging difficult compared to just
adding a
new opcode to the csound (or any other) source tree, and then rebuilding.

3. Especially with a program like csound (which has many target platforms)
managing
the "wiring-standards" (actual plugin standards eg. COM, CFM, .so etc.)
which are
platform-specific for all intensive purposes, would  be a major undertaking.
(Linux or GNU progams don't need to address this within the common source
tree)

4. Developing a csound specific plugin architecture would be potentially
easier that
defining a "common" cross-product standard, as the interfaces for a csound
plugin are already clear from the design (and from existing plugin
implementations).

5. There are different ways of managing versioning of plugins - but any
technique is
basically going to result on .orcs that won't compile on all versions of
csound + plugins.

6. Traditional component development often uses or accomodates the idea of
"adapters" - these allow one plugin format to be used within a framework
that
dosn't specifically support that format (an example would be to support VST
plugins
in csound). In the area of audio DSP (especially synthesis opcodes rather
then
full blown effects) this can be an unsatisfactory solution due to
comparativly high efficiency requirements. So a program-specific format
is preferable - but reduces the utility of the plugin format (see below).

Well that's all that comes to mind right now... no doubt there are other
issues. My
personal bias is to create a plugin architecture that is designed for use in
a lot
of different software - this is what the new "component-oriented" paradigm
is all
about. Developers (hobyists and professionals alike) are more likely to
contribute
to the pool of plugins if they will run on a number of different platforms /
products.

If csound plugins are too specific to csound what's the point? You can
always
email jpff with your code if you want everyone to use it.

Ross.