This feature request has 7 votes but it is orphan. Who wants to adopt it?
This request has 8 votes. Not bad! It is one of those that I created based on a topic on Reddit. It is orphan. Does anyone want to adopt it? Last time I ask. 
Reopened at a request of a volunteer. 
Hi, I’m that volunteer!
1 Like
Welcome @gutslyoir ! Thank you for bringing back a feature request with 9 votes from the nether! 
It looks like I still dont have the option to edit the OP even though I have ownership now… Any ideas why that is? Did I miss a step?
Oops! It should be fixed now.
The title kind of says it all but there’s still no details. This is a great suggestion I am surprised isnt already in the product
Details added!
2 Likes
Very good! Thank you for reviving this request, and with style.
I have copy-edited the first section, hoping that the changes make the requests clearer.
I have moved the text of the problem statement to the first section, because it was explaining the potential of the request, not the current problem users find. Below you have added enough details explaining what users can do with Bitwig or with VSTs. A sentence or two summarizing the current situation would be enough.
ReCycle is developed by Reason, so I guess reason can be mentioned as a DAW supporting this feature as well?
Ohh yes we need this! I’m just switching from Studio One to Bitwig and this was one point I was a little disappointed in as I use that quite often and had a great workflow in S1.
In S1 there’s the option to adjust settings (threshold) for the “onset” detection though.
In this image it’s at 26% and there are relatively few onsets /bend markers
Here’s it’s at 85% and they increased in count.
I would suggest, that this is a really neat feature and when they get to the quantize thing should also consider implimenting this one as it makes the workflow even faster & easier.
Please see edits. I am second guessing the suggestion of ReCycle/Reason now because I think they actually avoid stretching audio and only shift the timing of slices, making them roughly equivalent to whats in Bitwig now. So really it seems like Ableton is the most apt comparison. I am not a Reason user though so maybe someone else can comment on that.
Thank you for the information!
I have added studio-one to the description and the tags.
Bitwig already can do this, and I believe it is understood that any Audio Quantize implementation should come with this possibility to define threshold for onsets. However, if you, @gutslyoir or anyone prefers to play safe, you can mention this in the description.
Very good!
I have remove this mention to be safe, and I have added an invitation to make suggestions instead. The description an be always be improved later.
Very well, I’ll wait 48 hours just in case, and then I’ll promote this draft to Features.
Can you point me to it? I can’t find that. I found an “Intensity” setting in the inspector panel when clicking on onsets, however that doesn’t seem to change anything.
Gasp, you’re right. There is no threshold for Onsets on Bitwig. I guess I got mixed up with the discussion about Tempo follower, where Onsets and threshold are involved, but through the Replacer device, and in that case the thresold refers to dB.
But still, maybe that thresold on Studio One is also measured by the same criteria as the Replacer? In the end the goal for this feature request is to detect the beats of the audio to quantize them, and those beats probably can be found through dB threshold (wild guess, I’m not an audio expert).
In conclusion, the idea would be that this Audio Quantize could detect the points to quantize automatically through Onsets (good for discrete sounds like a kick or bass hits) or through dB thresold like the Replacer device does (better for more dense audio?).
Not an expert on coding either, but I don’t think it should be too hard seeing everything else that works similar to this in bitwig. I don’t know how S1 does it under the hood, but it shouldn’t be too different from a threshold setting in a compressor or so.
Audio Quantize would create a beat marker for every onset and then quantize the beat markers accordingly.
Also why not get rid of the differentiation between onsets and beat markers anyway? I don’t really see a reason for them to be two different things. If there is, enlighten me ^^
Hi! I can chime in wrt onsets vs beat markers. An onset is intended to be any transient in an audio event, and not all transients in an audio event are intended to be on a particular beat. A beat marker is intended to represent a point in the audio event that is expected to be “on beat.” The difference is notable depending on which stretch algorithm is being applied, and how much “groove” there is in a particular audio event. To clarify what I mean specifically about groove - I’m considering groove to be deviation from “computer perfect” with regards to: timing on the beat grid, velocity/envelope shape, and note length.
I work with breakbeats a lot, most often sampled from old soul and funk songs. Some of these are almost perfect by default, even though they were laid down by a human drummer. For example the amen break - the last bar or so of it is effectively a perfect loop on its own, it sounds alright at any speed, it loops without any need for stretching - just needs to be adjusted for sound taste depending on the sample source. Some breaks, however - sound wonderful in context of the song itself but are barely usable as a dry loop because the groove is extreme - the kicks and snares are nowhere near on time, ghost notes are less than ghostly and maybe more prominent than one would hope, crash symbols ring for long durations, etc.
In some of these cases, if you use a stretch algorithm that can be applied at onsets, it might not sound right at all when using onsets as the rate because the timing is so far off. One might be tempted to adjust all the transients to be “on time,” but there’s a problem: this has a side effect of stripping all the “soul” out of the break, which was likely “the best part” (this is all subjective of course!) In these cases, using stretch to adjust only some of the hits such that they land on time might be a useful strategy. One may, for example, move just the obvious “big” snares to 2 and 4, or move the lead kick to 1, etc. Depending on the stretch algo (and all the other factors…) these minor timing adjustments might result in a breakbeat that’s a clean loop but still preserves the groove between the beats (i.e. it’s not all quantized, it’s just partially quantized.) After making this type of adjustment, the stretch algorithm will sound different depending on whether we choose “Rate: At Onsets” or Rate: “1/4 (or other time)” - and so, distinguishing between the beat markers and onsets offers that flexibility, which is important to me and likely others who have a similar workflow.
I would very rarely, if ever, want to quantize every onset, but I might want to quantize some - and in either case I still may choose to stretch via timing or onset periods, especially since the different algorithms have a noticeable difference depending on the length of the portions being stretched. The sound may be entirely different if there are 16 onsets in 1 bar vs 4, when choosing “At Onset” for the rate, etc.
Another thing I’ll add is that Bitwig is far from perfect in its onset detection, so I’d be wary of quantizing as a core part of a workflow if one expected the onsets to be exact by default. There are times Bitwig is not just a little wrong, it can be egregiously and hilariously incorrect at times when detecting onsets (and zero crossings, for that matter) - and in those cases someone would have to go in and manually edit anyway before quantize would work. That’s not to say audio quantize as a feature should not exist, just a note I thought was important to mention here.
2 Likes
Thank you very much for your in depth thoughts on this.
I’ve not dived that deep into drum sampling myself so this isn’t something which would come to my mind.
So I take my statement back and I now see that there’s reason for both to exist. In that case it would be beneficial for you to have some threshold etc. adjustments for the onsets though as it would make it a little faster before going in manually and fixing the onsets which were not placed correctly which happens and is not such a huge issue to me.
1 Like
I have updated the first paragraph of the description. What do you think?
I’ll move this request to #features , and if something needs improvement, we can keep improving it.