[gmpi] Re: My plugin system
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 9 Oct 2003 19:20:36 -0400
Thanks for your interest in this issue. However, I beg to differ with some
of your points.
Since Csound is now open source (LGPL), I do not think there would be any
problem with bodily incorporating Csound into GMPI. There would thus be no
need at all to re-implement the engine. Csound is cross-platform to the max
and would run on every platform GMPI targets, I think.
The reason SAOL got no attention is because, although it certainly is more
attractive as a language than Csound, Csound does possess the absolutely
critical advantage of actually having an efficient, working runtime, which
SAOL does not. It's no fun having a nice audio language that won't run in
real time.
You are quite right about strings, but that is something that could be
changed quite easily. There is no reason that the pfields in the Csound
instrument instance could not have a parallel array of type information, and
the Csound API could be made to provide a set of type conversion functions
to access string (and other type) pfields by type.
People object to Csound because the code looks ugly - both the C code and
the Csound instrument code. That is true, and I have sworn at it countless
times myself. Yet I have worked with Csound for years, I have contributed to
Csound, I have worked with many other software synthesizers, and I have even
implemented my own synthesizers from scratch in both Java and C++. As a
result, I have a lot of respect for Csound. It solves a lot of the problems,
I would say MOST of the problems, that we deal with in this domain
effectively and efficiently - though perhaps not, to the eyes of a C++
programmer, elegantly.
The Csound language is awkward because it is a compromise that allowed the
language runtime to be hand-coded - by stringently limiting the complexity
of the language. Then contributors have taken this simple "assembler" type
language and hacked away on top of it, not always with the same insight as
the original developer (Barry Vercoe).
Everything I say about incorporating Csound into GMPI as a runtime could be
applied to Serpent or SuperCollider server. Or to an efficient SAOL runtime.
Csound has the huge advantage of already existing, already working on many
platforms, and already having the right license.
Best regards,
Mike
============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://sourceforge.net/projects/silencevst/
============================================
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, October 08, 2003 11:19 PM
Subject: [gmpi] Re: My plugin system
> >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
>
----------------------------------------------------------------------
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:
