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 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
- new [chroma] and [chroma~] objects for pitch class profile of
spectrum
- new [phaseSpec] and [phaseSpec~] objects for phase spectrum
- new [tempo~] object for tempo estimation
- new [featureNorm] and [featureDelta] objects for feature processing
- new functionality for [featureAccum]
- running sum of feature input
- running mean of feature input
- simple moving average of feature input
- additional methods for [tabletool] (overlap_add, permute, drip,
as_set, dump_range, hps, valleys)
- [timbreID] can now output its database formatted as a FANN training
file for use with the FANN neural net library
- new zero-padding feature
Examples
- automation via audio features: gated reverb, multi-band compressor
- improved vocoder
- chromagram plotting
- key estimation
- audio segmenting based on BFCC deltas
- significant update to timbre space example
for much faster batch analysis
- uses new "chain_" message functionality to avoid redundant FFTs
radius in sequence (according to distance from center) or in random order
- works on all platforms with Pd 0.49 and Gem 0.94
- keyboard commands for navigation/mouse functions
- new mouseover functionality to play all grains within mouse
sequences, changing sequence playback behavior, level, speed, rhythm
- grain pitch transposition
- map features to Gem sphere size
- new "constellation" feature for making sequences of grains
- a constellation control panel for managing multiple parallel
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com _______________________________________________ Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce
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 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
- new [chroma] and [chroma~] objects for pitch class profile of
spectrum
- new [phaseSpec] and [phaseSpec~] objects for phase spectrum
- new [tempo~] object for tempo estimation
- new [featureNorm] and [featureDelta] objects for feature processing
- new functionality for [featureAccum]
- running sum of feature input
- running mean of feature input
- simple moving average of feature input
- additional methods for [tabletool] (overlap_add, permute, drip,
as_set, dump_range, hps, valleys)
- [timbreID] can now output its database formatted as a FANN training
file for use with the FANN neural net library
- new zero-padding feature
Examples
- automation via audio features: gated reverb, multi-band compressor
- improved vocoder
- chromagram plotting
- key estimation
- audio segmenting based on BFCC deltas
- significant update to timbre space example
for much faster batch analysis
- uses new "chain_" message functionality to avoid redundant FFTs
radius in sequence (according to distance from center) or in random order
- works on all platforms with Pd 0.49 and Gem 0.94
- keyboard commands for navigation/mouse functions
- new mouseover functionality to play all grains within mouse
sequences, changing sequence playback behavior, level, speed, rhythm
- grain pitch transposition
- map features to Gem sphere size
- new "constellation" feature for making sequences of grains
- a constellation control panel for managing multiple parallel
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com _______________________________________________ Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I assume maybe the issue is that you also have the timbreID object? But I also don't really think that could be a necessarily a problem, though I haven't tested throughly...
Em seg, 29 de jul de 2019 às 04:32, Alexandre Torres Porres < porres@gmail.com> escreveu:
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 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
- new [chroma] and [chroma~] objects for pitch class profile of
spectrum
- new [phaseSpec] and [phaseSpec~] objects for phase spectrum
- new [tempo~] object for tempo estimation
- new [featureNorm] and [featureDelta] objects for feature processing
- new functionality for [featureAccum]
- running sum of feature input
- running mean of feature input
- simple moving average of feature input
- additional methods for [tabletool] (overlap_add, permute, drip,
as_set, dump_range, hps, valleys)
- [timbreID] can now output its database formatted as a FANN training
file for use with the FANN neural net library
- new zero-padding feature
Examples
- automation via audio features: gated reverb, multi-band compressor
- improved vocoder
- chromagram plotting
- key estimation
- audio segmenting based on BFCC deltas
- significant update to timbre space example
for much faster batch analysis
- uses new "chain_" message functionality to avoid redundant FFTs
radius in sequence (according to distance from center) or in random order
- works on all platforms with Pd 0.49 and Gem 0.94
- keyboard commands for navigation/mouse functions
- new mouseover functionality to play all grains within mouse
sequences, changing sequence playback behavior, level, speed, rhythm
- grain pitch transposition
- map features to Gem sphere size
- new "constellation" feature for making sequences of grains
- a constellation control panel for managing multiple parallel
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com _______________________________________________ Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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:
I assume maybe the issue is that you also have the timbreID object? But I also don't really think that could be a necessarily a problem, though I haven't tested throughly...
Em seg, 29 de jul de 2019 às 04:32, Alexandre Torres Porres < porres@gmail.com> escreveu:
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 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
- new [chroma] and [chroma~] objects for pitch class profile of
spectrum
- new [phaseSpec] and [phaseSpec~] objects for phase spectrum
- new [tempo~] object for tempo estimation
- new [featureNorm] and [featureDelta] objects for feature processing
- new functionality for [featureAccum]
- running sum of feature input
- running mean of feature input
- simple moving average of feature input
- additional methods for [tabletool] (overlap_add, permute, drip,
as_set, dump_range, hps, valleys)
- [timbreID] can now output its database formatted as a FANN
training file for use with the FANN neural net library
- new zero-padding feature
Examples
- automation via audio features: gated reverb, multi-band compressor
- improved vocoder
- chromagram plotting
- key estimation
- audio segmenting based on BFCC deltas
- significant update to timbre space example
for much faster batch analysis
- uses new "chain_" message functionality to avoid redundant FFTs
radius in sequence (according to distance from center) or in random order
- works on all platforms with Pd 0.49 and Gem 0.94
- keyboard commands for navigation/mouse functions
- new mouseover functionality to play all grains within mouse
sequences, changing sequence playback behavior, level, speed, rhythm
- grain pitch transposition
- map features to Gem sphere size
- new "constellation" feature for making sequences of grains
- a constellation control panel for managing multiple parallel
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com _______________________________________________ Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui, 1 de ago de 2019 às 13:27, 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.
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:
Em qui, 1 de ago de 2019 às 13:27, 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.
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
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:
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:
Em qui, 1 de ago de 2019 às 13:27, William Brent
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.
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
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
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
Gesendet: Freitag, 02. August 2019 um 17:34 Uhr Von: "katja" katjavetter@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] [PD-announce] timbreID 0.8.1
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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:
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
Gesendet: Freitag, 02. August 2019 um 17:34 Uhr Von: "katja" katjavetter@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] [PD-announce] timbreID 0.8.1
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
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:
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:
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
Gesendet: Freitag, 02. August 2019 um 17:34 Uhr Von: "katja" katjavetter@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] [PD-announce] timbreID 0.8.1
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 :
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:
Em qui, 1 de ago de 2019 às 13:27, 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.
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
-- 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