[gmpi] Re: My plugin system
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 08 Oct 2003 23:19:35 -0400
>In Csound, an opcode is a virtual base class (though written in C) for nodes
>in a DSP graph. Csound has the richest set of nodes of any system I know.
as one of the few (only?) people who has completely reimplemented the
Csound language (as part of my now-dead Quasimodo project), i would
offer a strong caution against taking anything from Csound at all.
Csound is fundamentally a virtual machine, and as such requires a much
more complex host engine that any of the plugin APIs that we have
considered so far.
>I think this is an intruiging idea, but it would inevitably incur at least
>the overhead of an additional function pointer dereference and call on each
>node call, and almost certainly some marshaling overhead. Probably, since
>mostly we are dealing with floats and ints in the same address space, that
>could be fairly minimal. The power that could be gained would be large.
Csound offers *no* way of dealing with string arguments/parameters
that would be acceptable to most of the programmers here. Also, the
marshalling cost is quite significant when the semantic size of an
opcode is considered.
What you basically have when an Csound instrument is executed is a
linked list of pointers to a set of closures, each containing pointers
to arguments and a pointer to a function (thus representing the
opcode). the function is passed the closure as its argument. this
means that Csound contains a (rather ugly and haphazard) "language"
for defining the structure of the closure, and has to build and
maintain it for each and every opcode.
I can assure you that having implemented all this stuff from scratch
once, I would never do so again: a GMPI API that was modelled on this
would never be supported by my host app.
>It is also the case that if the host could wrap compiled Csound instrument
>templates, not just the opcodes, it could obtain from Csound a complete
>sub-graph compiled by Csound. This would multiply the power of GMPI
>fantastically - it would be a whole DSP language and runtime.
SAOL does this of course, with SAOL-C as a reference implementation. I
think this is an entirely different problem space than the one we have
been considering. SAOL is a very nice project, even though I have
criticized the extent to which it inherited Csound's syntactic crud,
and for people who want to do stuff like Michael has described, it
should get a lot more attention.
--p
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
