Hi all,
I've just finished an update for timbreID, version 0.8.1. It's available via deken for Linux/Mac/Win, and at https://github.com/wbrent/timbreID. The examples package is now available via the github README.
Here's a summary of changes below and a quick video of the updated timbre space example, which has a lot of new features: http://williambrent.conflations.com/mov/timbre-space-june-2019.mp4
Any and all feedback is welcome! William
Objects
as_set, dump_range, hps, valleys)
file for use with the FANN neural net library
Examples
Nice work William, love this lib. Thanks for the update and new tools, looking forward to checking them out.
Julian
On Sat, 29 Jun 2019 at 15:40, William Brent william.brent@gmail.com wrote:
Hi William, congrats on the update.
I got one question, any reason why not to call the library binary just "timbreID" instead of "timbreIDlib"?
This imposes a minor inconvenience that the user needs to specify the path and the library name, whereas if it were called "timbreID", you wouldn't need to worry to specify the path, as Pd would automatically find it.
Not sure if you had to do it this way, but I'd suggest you to consider changing it.
cheers
Em sáb, 29 de jun de 2019 às 11:42, William Brent william.brent@gmail.com escreveu:
Hi Alex, thanks for taking a look. Yes - the reason I ended up calling the single library binary timbreIDLib is that there was already a [timbreID] object in the library. I just wanted to avoid confusion. Looking back, I wish I had named that object something else. At this point I think I'd rather live with an awkwardly named library rather than change the name of any individual object within it, but I'm open to suggestions.
On Mon, Jul 29, 2019 at 3:55 PM Alexandre Torres Porres porres@gmail.com wrote:
Em qui, 1 de ago de 2019 às 13:27, William Brent william.brent@gmail.com escreveu:
My suggestion was to change the name of library, not the object. But I don't really understand the challenges involved (haven't really checked the code structure). Though I think it's feasible. What do you say? Have you considered it and thought it wasn't possible or worth it?
cheers
Maybe there's a trick someone can suggest, but I didn't think that was possible. There's a timbreID.c source file for the [timbreID] object in the library, and a timbreIDLib.c source file for building the whole library as a single binary. That calls the _setup() functions for all the individual objects and also has a timbreIDLib_setup function itself. So making the names the same would result in two timbreID_setup() calls that are supposed to do two different things. I never looked into ways to work around that...
On Thu, Aug 1, 2019 at 4:42 PM Alexandre Torres Porres porres@gmail.com wrote:
I'm pretty sure that there is only one "special" name that you need for a function and that is the setup entry point for the dynamic library that contains your external/externals, which is named after the file it's in. So, you could rename the setup function for the timbreID class because if your library calls it, it doesn't matter to PD what it is called. Then rename your whole library and it's setup entry point to timbreID, and then you should be able to have [timbreID/timbreID]
Alex
On August 2, 2019 6:29:44 AM PDT, William Brent william.brent@gmail.com wrote:
On 8/2/19, Christof Ressi christof.ressi@gmx.at wrote:
ah, for this to work you'd have to make sure that "timbreID_setup" is not exported... pd-lib-builder exports all non-static functions by default...
... because gcc exports all non-static functions by default. No need to hack Makefile.pdlibbuilder, a library makefile can overrule the default with:
ldflags := -fvisibility=hidden
right, so William could declare only "setup" with __attribute__((visibility("default"))) and in your makefile:
ifeq ($(make-lib-executable),yes) ldflags := -fvisibility=hidden endif
Note that this doesn't work on Windows because MinGW ignores visibility attributes. But there's a solution:
On MinGW, GCC exports all non-static symbols unless at least one symbol is declared with __declspec(dllexport).
For Windows, simply declare the library's "setup" function with __declspec(dllexport). "make-lib-executable=yes" -> only the "setup" function is exported. "make-lib-executable=no" -> the file containing the "setup" function won't be compiled, so all other non-static symbols are exported (as usual).
Christof
Thanks for all the thorough replies! I'll try working this in for the next update.
On Fri, Aug 2, 2019, 12:30 PM Christof Ressi christof.ressi@gmx.at wrote:
wow, it just hit me... if you just rename the folder to timbreIDlib, that inconvenience I mentioned is gone... no need for slash declarations! Though I think the other option is more elegant :)
Em sáb, 3 de ago de 2019 às 10:09, William Brent william.brent@gmail.com escreveu:
Maybe this: if you called the individual *_setup() functions from the timbreID.c/timbreID_setup() (in addition to the normal timbreID class declaration), then the user would have to [declare -lib timbreID] to have all objects loaded.
Le ven. 2 août 2019 à 15:29, William Brent william.brent@gmail.com a écrit :