Definitely more effective and slicker.
I guess it’s tailored towards a known source ("…extraction and evaluation of ecologically-meaningful soundscape components…") so perhaps that helps with efficiency/effectiveness?
A couple of other thoughts on this:
-
Being able to easily seed nmf queries (in this case, a single button). I remember that @weefuzzy mentioned something about making an abstraction which handles the creation of seeds in a more easy/automated way. That would make the exploration of seeding much more playful and…erm…fluid(?) since it probably takes a dozen objects and a couple minutes of coding to whip up a simple seed->nmf test.
-
The interface is quite slick, although I’m not a fan of open/web interface stuff since there is less standard/known behavior to mess with. I think it’d be possible to create slicker and more usable interfaces in Max (and SC/pd), which will be more useful for those languages going forward. (that being said, having more stuff like this in the knowledge exchange (is the /ke page dead for now?) would be welcome.
-
Are there going to (eventually) be provisions for dealing with “known” material types? As in, a lot of the discussion around the Sensory Percussion trigger stuff involved specific things that would have been done to the algorithms knowing that they would always be dealing with quickly decaying and short drum sounds. In this example here (not having read the paper), it is possible that there will be similar assumptions where there will be “background noise” and “different kinds of birds”. Obviously there are times where you want to explore unknown and potentially completely open and varied samples via nmf and what not, but other times there will be known inputs, that if it is possible to tune/tweak/optimize the algorithms for, would be useful, particularly if the tradeoff is a jack-of-all-trades-master-of-none algorithm(s).