Today we are releasing a new beta version of the FluCoMa Toolkit. This version is certainly going to break existing patches across all environments due to several interface changes. Primarily, these changes relate to how the
buffer~ ecosystem in Max and PureData works.
Thanks to everyone outside the team who has contributed to this release as well. We are seeing some more community contributions to the codebase which is exciting! A special thanks goes to @elgiano for his continued work on this front in helping us improve the Supercollider experience. This is likely to be the final beta release before the first stable version of the toolkit so we would appreciate any assistance from you all in identifying typos, mistakes or receiving your suggestions. Questions or issues can be flagged here on the discourse as well as on GitHub.
Links to releases below
There are some significant changes to how the
buffer~ objects work in this version and going forward. I’ve put together a short-ish video summarising those changes and how they modify the workflow of the FluCoMa objects.
We welcome any questions about how to navigate this new interface!
We’ve been working really hard to create a consistent and rich set of documentation for you to explore while learning and using the toolkit. It would be almost every object listed under this heading so instead, we’ll just encourage you to go and check out the documentation for your environment of choice. This is especially in PureData where many new help files can be seen. Thanks to @b4d455 for that work which is ongoing still. The Learn Platform has also been populated with a lot of new material which is worth checking out.
Till now, some parameters in objects were “clamped” by a maximum value set in another parameter or sometimes an argument. While annoying from a user perspective, these maximum values are used at the time of object creation so that memory can be allocated in advance. However, there are some quirks to this, especially about what you might expect to come out of the object.
An example of this can be seen here for
fluid.mfcc~ in Max where you ask for 13 MFCC coefficients:
Instead you might see a list of 40 values, where 27 of those are just 0. This is because the default maximum number of coefficients used to be 40. So the easy fix was this:
This is a tedious design pattern that adds cognitive overhead, especially in the typical example where you just want 13 MFCCs.
So the entire system of maximum values at instantiation has been reworked by @weefuzzy to follow these golden rules.
By default any parameter that sets the maximum is instantiated to a value of -1. This value indicates that the maximum will be the same as the specified parameter.
If you need to modulate the value higher than the default, set a maximum with the corresponding attribute or argument.
For example, let’s say we wanted to have 13 MFCC coefficients initially, modulated to 40 later after the object was created.
Alternatively arguments can now be used to specify significantly useful parameters (like numcoeffs).
This change should overall reduce the amount of “gotcha” moments, where you expect to receive 13 values but instead get 40, while still allowing a clean syntax for defining maximum parameters. It is worth revisiting the references and documentation to see how this affects each object now.
New object! SKMeans functions almost the same as KMeans except that it uses the cosine distance between points (rather than euclidian). This makes it potentially more useful for unsupervised feature learning. We hope to have some more expansive workflows documented for people to experiment with in the near future.
For a more technical perspective, this explanation isn’t too bad either: clustering - Difference between standard and spherical k-means algorithms - Cross Validated
Because of how the toolchain now reacts to changes in the core code, all of the buffer processing objects now have CLI counterparts. This means all your favourite tools now exist that didn’t before! This is personally exciting: you may see some new algorithms appearing in ReaCoMa.
BufNMF no longer resynthesises components and only computes the bases and activations. This resynthesis can take just as long as the actual decomposition process and is now toggled behind a parameter called
resynthMode. So, any patch where you depended on resynthesis needs to have
@resynthmode 1 or
resynthMode: 1 or
hidden parameter is now called
hiddenlayers for the neural network objects. This is because
@hidden is a reserved parameter in Max.
Multivariate descriptor objects such as BufLoudness, BufPitch, BufSpectralShape and BufStats now have a new parameter called
select. This is a quick way for selecting specific descriptors that you want from the output without having to cherry-pick channels or frames from a buffer. An example is here for getting just the spectral centroid and rolloff:
Caveat! This is a mask not a cherry-picker. The below example will produce the same values as the one above and will return the same channels in the same order. Think of this new parameter like a filter, built into the object.
For any object where the
select parameter exists, the ordering of constructor arguments in Supercollider may now be broken if you were depending on the position of those arguments and not keywords.
NMFMorph had its
interp parameter changed to
interpolation to match other objects with similarly named parmaeters.
For transformers that can invert their learned mappings (Normalize, Standardise, PCA etc…) no longer have an
invert parameter. Instead they have new messages or methods such as
invertTransform. This prevents the inversion being a piece of state that is shared between objects that have the same names.
BufNNDSVD object is now called
BufNMFSeed because the original name wasn’t very inviting. If you like
BufNMF check out the documentation for this really powerful object!
size parameter is now
New audio file contribution by @rodrigo.constanzo
Thanks to @rodrigo.constanzo one of his percussive examples is now included in the documentation.