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
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
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@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
Guenter,
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?
Karl
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@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
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.
Larry Troxler
Karl MacMillan wrote:
Guenter,
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?
Karl
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@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
-- _____________________________________________________ | Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
-
Guenter Geiger -
Karl MacMillan -
Larry Troxler