I get that, but at the same time a curated list of settings/approaches for diff materials is equally useful, given that you’re aiming for the techno-fluent crowd (and not the programmer crowd). I’m assuming that’s in the works, and us being first batch obviously will live through most of the growing pains. But taking the example of fluid.ampslice~, I kind of understand what’s happening with the algorithm since the Max version has been my go-to onset detector for a couple of years now, and after making the thread asking questions, I understand (most of) the parameters, but I’m not using it in any of my patches. It doesn’t make sense to me. (part of that is I haven’t been able to get consistent results across a range of test material, so I don’t feel comfortable that it will behave as I expect in a performance context)
I guess that’s a main part of it for me. What if I want to make a lot of assumptions about the material I’m using, in order to excel in a single task. That often isn’t exposed architecturally.
(so here I’m not exactly sure what I’m asking for other than knowing that with comments like yours, because those approaches are assuming things, it lets them do stuff that isn’t possible a general purpose algorithm(ic approach).)
I know you often use this as a negative thing, but FluCoMa isn’t exactly not a black box either. There is a paradigm that is absolutely locked in, and based on assumptions on how users will use things (a single example is the buffer-based paradigm, which comes with a lot of baggage, is completely blackboxed in that there is no other way of doing things).
I don’t mean to (further) suggest that should change, but just to point out that there is no such thing as a neutral or open system. They all makes assumptions, restrictions, limitations, etc… So to say that FluCoMa is fully open, just means that it lines up with your assumptions (which obviously makes sense, since your driving the project!).