Beta 7 Release
Hi everyone,
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 fluid.dataset~ and 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 
Supercollider
Max
PureData
CLI
Buffer and DataSet Interface for Max and PureData
There are some significant changes to how the fluid.dataset~ and 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!
Documentation Improvements
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.
Max Parameters
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.
SKMeans
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
CLI Compilation Updates
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.
Resynthesis and BufNMF
By default 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 -resynthmode 1.
hidden is now hiddenlayers
The hidden parameter is now called hiddenlayers for the neural network objects. This is because @hidden is a reserved parameter in Max.
Select parameters
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.
interp → interpolation
NMFMorph had its interp parameter changed to interpolation to match other objects with similarly named parmaeters.
invert parameter has been changed
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 invertTransformPoint and invertTransform. This prevents the inversion being a piece of state that is shared between objects that have the same names.
BufNNDSVD is now BufNMFSeed
The 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!
FluidStats (the realtime version) parameter changes
The size parameter is now history.
New audio file contribution by @rodrigo.constanzo
Thanks to @rodrigo.constanzo one of his percussive examples is now included in the documentation.