There are lots of library that uses one big file for all objects : Gem, zexy, Cream library (from Cicm) amongs others. The key is to call each object's setup method in the library setup method.
Cheers antoine -- do it yourself http://antoine.villeret.free.fr 2017-07-11 20:43 GMT+02:00 William Brent <william.br...@gmail.com>: > Yes, one library file is sounding more and more like the right way to go. > I've never done that, so if you can offer any simple examples to look over, > please do. But apart from individual binaries vs one big binary for the > whole library - I'm not even sure how to link statically on Windows with > the FFTW .dll. I did succeed in producing a .a file using MinGW/dlltool ( > http://www.mingw.org/wiki/createimportlibraries), but couldn't get it to > work in the end. If anyone who has done static linking of FFTW 3.3.5 on > Windows is wiling to hear my gripes, please let me know. I can post more > detailed info on the errors I got. > > On Tue, Jul 11, 2017 at 11:43 AM, Antoine Villeret < > antoine.ville...@gmail.com> wrote: > >> on my side, I always make one file library, all objects are included the >> same binary, >> thus I link only once to FFTW (or something else) and then the size it >> not so big >> when linking dynamically its always a mess with rpath at runtime for a >> crossplatform project. >> moreover you can have a better control of the version and the feature of >> the library you use. >> >> cheers >> a >> >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> 2017-07-11 0:11 GMT+02:00 William Brent <william.br...@gmail.com>: >> >>> Yeah, that was one of my dilemmas...static or shared. The individual >>> binaries were bigger when I linked statically, so I opted for shared on Mac >>> to make the whole package smaller. On Windows I could only figure out how >>> to set it up as shared. But maybe it's easier to have large binaries than >>> it is to require that people install FFTW... >>> >>> On Jul 10, 2017 5:26 PM, "Antoine Villeret" <antoine.ville...@gmail.com> >>> wrote: >>> >>>> Thanks for that work ! >>>> >>>> Concerning the FFTW dependency, I made a restoration tool (by porting a >>>> LV2 plugin) that uses FFTW library and the easiest way to deploy on OSX was >>>> to link statically to FFTW. >>>> I have to rebuild FFTW from scratch because there is no more static >>>> version of that library in brew, but that was quite easy so far. >>>> >>>> Cheers >>>> >>>> Antoine >>>> >>>> -- >>>> do it yourself >>>> http://antoine.villeret.free.fr >>>> >>>> 2017-07-10 22:45 GMT+02:00 William Brent <william.br...@gmail.com>: >>>> >>>>> Hi all, >>>>> >>>>> I've finally gotten around to making some improvements and updates to >>>>> the timbreID library, so I'd be grateful for any feedback and bug reports >>>>> at this point. You can currently get source code and Linux/Mac/Windows >>>>> binaries via deken. Below is a short list of the main additions. One major >>>>> point is that I decided to use FFTW this time around. I've managed to get >>>>> that working fine on Linux/Mac/Windows, but it would be great to get any >>>>> advice on how to minimize the trouble that that dependency brings up. >>>>> Makefile edits and suggestions are also very welcome, especially aspects >>>>> that involve linking to FFTW on these 3 different platforms. >>>>> >>>>> UPDATES: >>>>> Bark-based versions of all spectral features (barkSpecCentroid~, >>>>> barkSpecSpread~, etc.) >>>>> A cepstrum-based pitch tracker (cepstrumPitch~) >>>>> An attack time analysis object (attackTime~) >>>>> Spectral slope analysis objects (specSlope~, barkSpecSlope~) >>>>> A waveform slope analysis object (waveSlope~) >>>>> A DCT object (dct~) >>>>> Various simple time-domain objects (peakSample~, minSample~, >>>>> maxSample~, minSampleDelta~, maxSampleDelta~) >>>>> Various conversion objects (bin2freq, bark2freq, etc.) >>>>> Additional [tabletool] methods (clip, round, ceiling, floor, maximum >>>>> magnitude, find zero crossings, mtof, ftom, dbtorms, rmstodb, bin2freq, >>>>> freq2bin, bark2freq, freq2bark, auto-fit boundaries) >>>>> Various improvements to the database/classification object [timbreID] >>>>> >>>>> There is also an updated examples package, which mainly addresses the >>>>> change in functionality of [timbreID]'s fourth outlet, but has significant >>>>> improvements for the concatenative and timbre space examples. It also >>>>> includes a new example directory for audio segmentation. You can get that >>>>> at http://williambrent.conflations.com/pages/research.html#timbreID. >>>>> I've also set up a GitHub repo at wbrent/timbreID, which has everything >>>>> (source, binaries, example patches). >>>>> >>>>> Thanks and feel free to write me on or off list. >>>>> William >>>>> >>>>> >>>>> >>>>> -- >>>>> William Brent >>>>> www.williambrent.com >>>>> >>>>> “Great minds flock together” >>>>> Conflations: conversational idiom for the 21st century >>>>> >>>>> www.conflations.com >>>>> >>>>> _______________________________________________ >>>>> Pd-list@lists.iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >>>>> stinfo/pd-list >>>>> >>>>> >>>> >> > > > -- > William Brent > www.williambrent.com > > “Great minds flock together” > Conflations: conversational idiom for the 21st century > > www.conflations.com >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list