Thanks for your consideration of this topic.

I agree it should be possible to formulate a generic plugin format for
function table and data flow graph based synthesizers such as Cmusic, m4C,
Cmix, Csound, JSyn, and most shareware or freeware software synths.

To be most generic, these should be COM interfaces (non-COM platforms can
just ignore the three IUnknown methods required by COM):

To start thinking about:

interface IFunctionTable : public IUnknown
{
    // Implement IUnknown.
    virtual long QueryInterface(IID globalInterfaceID, void **ppIUnknown);
    virtual long AddRef();
    virtual long Release();
    // Function table methods.
    virtual long Initialize(long parameterCount, float *parameterFields);
    virtual long GetSample(float sampleIndex, float *sampleValue);
}wn

interface IDSPBlock : public IUnknown
{
    // Implement IUnknown.
    virtual long QueryInterface(IID globalInterfaceID, void **ppIUnknown);
    virtual long AddRef();
    virtual long Release();
    // Return name and parameter count and types in the arguments, to fill
in the synthesizer symbol table
    // (COM TypeInfo is another mechanism that could do this more thoroughly
and flexibly).
    virtual long Register(wchar_t *Name, long parameterCount, wchar_t
*parameterRates, wchar_t *parameterTypes);
    // DSP data flow graph block methods.
    virtual long Initialize(IFunctionTable **functionTables, float
sampleRateHz, long parameterCount, float *parameterFields, long sampleCount,
float *sampleBuffer);
    virtual long ControlTick();
    virtual long AudioTick();
}
-----Original Message-----
From: Ross Bencina 
To: csound@maths.ex.ac.uk 
Date: Wednesday, January 20, 199n9 9:02 PM
Subject: Re: plug in architecture?


>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.
>
>
>
>