C++ wrapper for extern development
lt at westnet.com
Tue Aug 1 13:46:40 CEST 2000
Hi Guenter, Karl...
No, I haven't thought seriously about how one would go about it, but
just wanted to know if something had already been done before I thought
about it too much.
I agree, that the C api is pretty straightforward, once it is learned.
What I was thinking of was the possibility to use some template magic in
C++ to simplify the notation, eliminate all the casts, for example, that
are involved in using the var-args passed to the DSP processing
functions (for example). But I don't know if this is possible, and I can
think of a couple of things to consider - (1) Can a C++ interface really
avoid someone having to learn the C API anyway? (2) Can this be really
done just as an add-on (proxy classes, etc) without having to touch the
existing infrastructure? (3) Can it be done without loss of efficiency
in the run-time processing?
Well, like I said, I haven't thought about this in detail much at all,
and was just asking if others have already thought this through.
Karl MacMillan wrote:
> Glad to have your thoughts on this (I have been meaning to look at Gem for
> the purpose of C++ wrappers for a while, but haven't gotten around to it).
> I think that it is going to be difficult to make externals much simplier -
> the C api is pretty straight forward as it is. I was thinking more in
> terms of providing subclasses of the wrapper base class that define
> standard types of objects - 1 in / 1 out cotrol object, 1 control in / 1
> dsp out, etc. Implement a few virtual functions and you have an
> object. Does anyone have any better ideas?
> I almost think what would be better would be an object 'wizard' - a simple
> script to ask some questions and generate all of the boiler plate code for
> you and you just fill in the functions. More interesting would be to get
> it to generate all of the boiler plate code for PD, Max/MSP, and
> jMax (along the lines of fiddle)! Any thoughts?
> On Fri, 3 Nov 2000, Guenter Geiger wrote:
> > Gem is really targeted for doing graphics, so it is only partly
> > useable as a base class for pd external objects (look at
> > src/Base/CPPExtern.h).
> > The C++ wrapping of Gem does not really (IMO) take away the complexity
> > of creating externals.
> > This said, it may be a good starting point to investigate how it can
> > be done.
> > I haven't really analyzed the design thouroughly, the drawbacks of
> > GEM's wrapping are:
> > - uses #define instead of templates ( this makes it easier portable to
> > some extend).
> > altough the defines reduce the amount of typeing needed for each
> > external, they do not really clarify what is happening.
> > - adding of messages becomes more complex than in plain C.
> > despite that, having a C++ wrapper would be great, though I think
> > creating a decent API is not that simple.
> > Do you have any concrete suggestions ?
> > Guenter
> > Karl MacMillan writes:
> > > Have you looked at Gem?
> > >
> > > Karl
> > >
> > > On Tue, 1 Aug 2000, Larry Troxler wrote:
> > >
> > > > Just wondering, has anyone thought about writing some C++ classes that
> > > > wrap the existing PD code that is used to create classes?
> > > >
> > > > I'm not suggesting modifying the existing PD core, but rather, having
> > > > some classes that encapsulate it, in order to make it easier to code new
> > > > externs, and to make it more understandable what is going on.
> > > >
> > > > Larry
> > > >
> > >
> > > --
> > > _____________________________________________________
> > > | Karl W. MacMillan |
> > > | Computer Music Department |
> > > | Peabody Institute of the Johns Hopkins University |
> > > | karlmac at peabody.jhu.edu |
> > > | www.peabody.jhu.edu/~karlmac |
> > > -----------------------------------------------------
> > >
> > >
> | Karl W. MacMillan |
> | Computer Music Department |
> | Peabody Institute of the Johns Hopkins University |
> | karlmac at peabody.jhu.edu |
> | www.peabody.jhu.edu/~karlmac |
More information about the Pd-list