Hi, 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. Naturally, i use flext for nearly everything and i have had no real problem compiling it in the last couple of months. I also think that the new build system should be easy to use but it may not be fit for the complex building involved with readanysf~. The last time i tried to build readanysf~ for Windows i had the impression that the problems are not caused by flext, but i didn't really understand the code - that's why i chose to write my own flext-based soundfile player (although i doesn't decode MP3, because i don't use crippled sound) It's true that flext has changed a bit in the last time, but not the API, just the naming of the libraries, so that it's uniform across several platforms. I think that should be trivial to adapt. The API itself hasn't changed for the last two years or so. It seems to be at least as stable as the pd API.
best greetings, Thomas
Am 04.02.2005 um 10:33 schrieb IOhannes m zmoelnig:
august wrote:
on another note, I started to rewrite the readanysf~ code. the goal for the new version are as follows: 1.) direct c++ code for pd. no more flext.
what are the advantages of such an approach ?
or rather, what are the big disadvantages of using flext ? 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 ? or is the flext-api highly unstable (so that it is a pain to upgrade from one version of flext to the next ?)
mfg.btr.xs IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list