General purpose vs Specific use case (or: secret sauce, and where to get it)

tremblap · October 17, 2019, 7:45am

the problem here is the extant of the diversity of examples. Just look at onsetslice for instance. Changing the metrics changes everything, and the very carefully curated list of audiofiles barely scratch the surface of what creative sound designers might care about…

that is why the industry does blackboxing. Physion barely works, and most database sorters are for small single file percussion, and all concatenative orchestration package I found are complex in interface… and drum trigger people do something you like because they have taken a very, very, very narrow subset of possibilities. What is the ethos of our project from the onset is to give composers more power, therefore more responsibility. As @weefuzzy said, the interface balance is to be tweaked, but we already have curated quite a lot of the parameters… just look at this:

github.com

IoSR-Surrey/untwist/blob/master/untwist/factorizations/nmf.py

"""
Non-negative Matrix Factorization algorithms.  Many can be unified under a
single framework based on multiplicative updates.  Implementation is inspired
by NMFlib by Graham Grindlay Currently implemented as processor for
flexibility, so W and H are not kept in the object, the user is supposed to
manage them.
"""
from __future__ import division, print_function
import numpy as np
from ..base import algorithms
from ..base import defaults


class NMF(algorithms.Processor):
    """
    General NMF class, including euclidean, kl and beta-divergence
    implementations. For supervised NMF, typically set update_W
    to false in the constructor and provide a W0 to the process method
    """

This file has been truncated. show original

This is a very well curated, yet one level further down than FluCoMa (devised by @groma in a previous life). There is even more open. Then look at this: http://audiostellar.xyz/ or this http://imtr.ircam.fr/imtr/CataRT - both of them assume a lot, and will excel in a single task (the former towards very short sound, the latter towards granulation with semi-perceptually relevant parameters)

===
So where does that leave you:

on extreme: if there is a commercial product that does what you want, use it. It’ll very likely be better than anything you’ll do by yourself
other extreme (not your case for sure): if you are not afraid of doing DSP, prototype in Python then code in C++, you’ll have a lot of control on a lot of details we already curate.
if like me, you are dissatisfied by the level of curating of commercial software and you are ready to experiment with something in Max/Pd/SC, then you are at the right place. But you have to keep expectations are a research project exploring interface, not a service to specific needs. The overall agenda is flexibility of interface, which comes at a double cost of 1) more knowledge needed (hence the KE work of @weefuzzy and all the example and this forum) and 2) more explorations needed and 3) trial and error on all sides.

I’m sure you heard me explain that before, but it is very important that everyone understands the agenda: neither of the extremes in the above list, but a new possibility. For my case, as you will see in the next plenary presentation, the FluCoMa tools do things that are not possible elsewhere, and complement a workflow with many other things.

Happy experimentation!