the interface I work on with @groma allows to fine tune these settings, so we could make a few preset in the helpfile/example - tight percussive material, low end heavy, etc.
I can see you still not use my ‘first past the pole’ version where the median filter differential and the dual-average differential are competing. I will test and edit this post to see if I get better results
edit: the results are different. It definitely confirms that we need these parameters to be available, and more importantly, with examples for each settings, since your super nervous one is failing on the bass stuff (Tremblay-AaS-SynthTwoVoices-M) and on the full program (Tremblay-BeatRemember) it catches stuff I’m not sure I like. Anyway, all good research here for fun!
Also, for info, the decay time of the peak follower (the fast asymmetrical) will indeed influence the reset time of the Schmidt trigger (slower or faster to decay, or how nervous it follows the rectified peak). Does it make sense?
Indeed. That’s what occurred to me to experiment with since I wasn’t getting a response time that was anywhere near the lockout time in terms of resetting. So I started looking elsewhere in the code to catch it.
One thing I started experimenting with, but got nowhere useful, was having dynamic threshing or dynamically adjusting slow envelope that “rides” the overall amplitude better, so it can still be fast, but not uber nervous during quieter things.
I’m sure there is some literature on the auto-release parameter of compressor that can help your explorations there. The paper mentioned earlier is quite good I think (Giannoulis, Dimitrios, Michael Massberg, and Joshua D. Reiss. “Digital Dynamic Range Compressor Design—A Tutorial and Analysis.” Journal of the Audio Engineering Society 60, no. 6 (2012): 399–408.)
Getting back to piano writing with some more realtime onset detection questions for you.
I looked at PA’s and Rodrigo’s solutions. But for piano with changing pedaling and no need for snare-drum speed repetition, I’m not getting good results with your solution.
Here is a different attempt, but it does not work well either.
I’m using threshold and have it ‘float’ over the past 500ms of average energy.
That technique has worked quite well in the 1990th, when no other attack detection
was reliable - instead of looking at absolute values, I’m making them relative to the past
energies.
In order to prevent re-triggering, I’m now also looking at the pitch and try to control
a time gate with it (slower for low notes, faster for high notes).
This is VERY experimental and does not lead to good results yet.
Any thoughts on how to get good attack detection on the piano
I’ve done something like this with @jamesbradbury for his distorted pedal steel: make a very short HPSS, and run onset on the percussive channel. That is quite sturdy. Maybe @jamesbradbury will share the final bit of patch?
This is already in the gen~ examples here. There is a proper object coming in Alpha06 doing that with some very good controls I’m currently experimenting on with @groma.
@tutschku I am doing some piano segmentation myself . I’ve found really good results using a variety of preprocessing techniques (as described by @tremblap above) and some of the less straightforward functions in fluid.onsetslice~.
The setup I used for the lap steel is applicable to the piano to it seems, and so the last bit of the patch looks something like this. hpssonset.zip (861.1 KB)
I’ve provided a short piano sample too, although I suspect you will want to test on your own material. fluid.hpss~@masking mode 1 is also useful, although not so good for real time as it functions best with a big fft window and thus lags for real-time use.
EDIT: Apologies if the patch is not super clear, it was cut out fairly hastily. Thresholds aside, the key is to have a really small @harmonicfiltersize and very tiny fft’s for everything. I used @function 9 with fluid.onsetslice~ as this seemed to be the most responsive. @function 1/2 work also, but you have to be very particular with the threshold.
Here is the “really fast roll” test/comparison patch I showed during the 2nd plenary.
I also have some audio files I test it with, but perhaps too big for the forum. Several options for testing here, along with the ability to add in some noise to test the robustness of the settings.
I presume this is there to time-align the analysis window of 128 samples further down the patch, but using 2ms instead of 2.90249 (128 samps @ 44.1k) to allow for some snapshot~ “slop” in pd land.
Since snapshot~ doesn’t have an offset inlet in pd is there any way to ensure that the sample taken is always the correct one?
I’ve basically coded this up in pd and don’t notice any discrepancy between them, but since I’m not using change~ anymore, I don’t know if @a.harker’s test example is still valid:
There’s also also the *~ -1 → +~ 1 before the samphold~ too. It works fine without it, but I presume this is because samphold~ triggers on a decrease in value in pd?
Had to do some more debugging today, but it turns out. my “256 sample delay” bit wasn’t working properly. Fixed it now and it seems like it’s working correctly.
Doing the debugging trick where I fluid.bufcompose(~) the bit, and comparing the results from Max/pd and in all the hits I’ve done (not super comprehensive), the results are the same all the time.
It would be good to force this in code in case the accuracy above is accidental.
