[PD] C++ for pd (was: mp3 playing external)

[august]

> i think the main problem flext and readanysf~ might be the latter's
> dependance on a large number of external libraries, although i don't
> know which kind of clash that could cause.

actually, the biggest problem for me at the moment is the object wrapping
that exists in flext.  now, whenever you delete() a C++ object using a
flext version greater than 4.5, PD will crash hard.  There is a switch in
flext, but expecting users to turn this off is a bit too much.

> > what are the advantages of such an approach ?
> >
> > or rather, what are the big disadvantages of using flext ?

well, initially, I thought it would be great to easily compile pd
externals for MAX.  but, the chances of me ever getting around to taking
the time to sit in front of a macintosh or windows machine and compiling
an external are now becoming more and more slim.   and, if you are writing
in C++ anyway, then you probably have your objects in a decent enough form
to just switch from the pd api to the max api.


> > i do not use it myself (since Gem has its own C++ framework and my
> > rest is done in C), so my ideas of flext might be clouded.
> > the only reason to not use it that is see, is an additional
> > dependency. isn't it possible to link statically against flext, so the
> > dependency would only exist at compile time ?

you could link statically, but then it adds some uneeded KB (about 90kb I
think) to your external.  and if you load 20 of an external, this is a
pretty heavy hit.

> > or is the flext-api highly unstable (so that it is a pain to upgrade
> > from one version of flext to the next ?)

except for the changes from 0.4.5 to 0.4.6, flext has proven to be
extremely stable.

and, like frank said, you will probably want flext anyway on your machine
to get Thomas's awesome externals.


best -august.