If I’m aiming for an increase in accuracy of a small amount of samples (say 128samples), leaving signal-rate, banging some
fluid.buf~ objects, and then back, would negate any benefits from the increased accuracy.
I guess the two use cases, to explain it more along those lines, are:
- Literally have a gate output version of
fluid.ampslice~ where you get a 1 when it crosses the thresh, and a 0 when it returns. Fast and real-time, like a variable duration click.
- When I’m interested in having more precise onset (relative to the incoming signal) and don’t mind some extra samples in latency. Again, fast and real-time.
The features of the split up objects don’t seem to allow either of these use cases.
I don’t think the joined up object allowed for these use cases either, but it was harder to tell. This is another situation where it would be powerful if objects that make curves are split up from objects that segment curves I guess.
(1) is trivial to build in Max, except for the signal rate debouncing, which I think would need gen~ if you wanted a gate-like output. (2) is harder, because it sounds like you want all the complex state management of ampgate~, but working on the difference of two envelopes.
I didn’t really play with the original one enough to understand what it actually did, but did the original allow those use cases? I understand the topology of what is now
fluid.ampslice~ but never understood where what is now
fluid.ampgate~ fit into the equation.
The first use case would be covered with something like an output flag in
fluid.ampslice~ where you can set
@output trigger or
@output gate or something like that. Presumably, like the Max-version of the algorithm, the threshold exceeds the value and then drops below it in a way that is reportable, the object just does the
edge~ thing and says it has passed on does nothing after that.
thresh~ would do it in Max-land, but then needs the debounce stuff, so it would be basically rewriting the object, in Max, to get the access to the full state of the object.
For the second one, I can see myself using something like that sometimes, though not very often. It was mainly me spitballing because that’s what I thought the purpose of the object was meant to be (the onset stuff but with crazy time management things).
Other than functioning something like a noise gate with funky time stuff, I don’t really understand the point of
fluid.ampgate~. I mean, a noise gate is cool and all, but the time stuff seems wasted on that as a function, particularly in the overall scheme of the
With the introduction of
fluid.ampfeature~ I’m reminded by how useful it would be to have the “offset” of the internal thresholding be the output of
fluid.ampslice~ instead of just the onset.
Most things in MSP-land will be just as happy with a gate as they are a trigger, and
edge~ doesn’t care one way or another, and it would add richer output as the variable gate length, in-and-of-itself, could make for a useful pseudo-descriptor or for plugging right into an adsr or something.
But now that you have
[fluid.ampfeature~] you can just stick
[thresh~] afterwards and have that…
Would have to manage my own lockout though, which isn’t the end of the world.
Just curious if it’s a technical funky thing to implement, a “not enough hours in the day” kind of thing, or an interface/differentiation thing. Just seems like nothing is lost by having it output the off threshold (which is also used for this sort of thing) instead of just the on.
Well, it’s definitely not enough hours in the day thing besides anything else. I also suspect that without adding a Schmitt trigger a la
ampslice doesn’t currently have, IIRC), the offset output would be really (really) noisy. Part of the motivation for breaking out the
<x>feature objects was that it leaves advanced users like you much more room to experiment, without needing to keep adding more to the original objects.
Does it not use a Schmitt? I thought that’s what the separate on/off threshes were doing either way. Which is why I was pushing on this back then (and again now) as I thought it was just a matter of changing what variable gets output, rather than adding anything else in since presumably the offthresh is computed to get passed onto the thresholding regardless.
My mistake, it does have a Schmitt trigger.
Here is gen code to do what
ampslice~ does, plus output the state
if(state == 0 && in1 > onThresh && prevValue < onThresh && debounce == 0)
out1 = 1;
debounce = minSlice;
state = 1;
if(debounce > 0) debounce = debounce - 1;
if(state == 1 && in1 < offThresh && debounce == 0)
state = 0;
prevValue = in1;
out2 = state;
Here is an updated version (using the same variable names as
fluid.ampslice~ for the sake of my sanity) as well as a “musical example”.
I can see myself using this in just about all of my use cases…
I guess having a similar output with
fluid.bufampslice~ is not so hackable, since the curve/computation is not exposed?
Would be handy to do a similar process to above, but on buffer-based samples.
Well, in the first instance, you could use the code above with the non-tilde
peek~ your way through.
I guess I meant more for the context of having a longer buffer analyzed and getting the separate ‘onsets’ and ‘offsets’ like you get out of
That’s what I had in mind
Ah super handy!
These abstractions should end up somewhere in the final distribution (snippets or whatever).
Maybe. I’m reticent about adding too much more stuff to repos without much sense of how shared maintenance is going to pan out in the future, especially given the current focus on trying to ensure that we have as much parity between hosts as possible.
That said, feel free to shine them up and put in a PR.
Something useful on the learn platform – if we can be bothered to collate and flag that its not maintained code but community code – would be to have a “snippets” area where people can peruse community sourced stuff. Keeps it out of the repos but makes it more exposed.
That’s a good idea.
Unless I’m gonna get into the core guts of the stuff, it doesn’t make too much sense to try to edit help files or add snippets if it’s not in the correct style, or going to be implemented at all, etc…
Nor should you feel the need to – having workable but dirty patches on this forum is fine. We can tackle discoverability as a separate issue later