There are four situations I’d like to describe that I find frustrating. I’d like to discuss if there is a feature or two that could simplify. In all the cases I described, I’m recording with a count in (preroll).
I have a 1 bar count in and am recording (midi) and want to play a note exactly on the 1 but I come in early ( sat a 1/128th before the 1): the note is lost
I have a piece of music that plays a note just before what mighty logically be considered the first bar (e.g an 8th note before the 1): I need to add an extra bar to capture it.
I have a clip recorded unquantized which I shrink to only include a certain bar which has a note played just before the 1: I either lose the note, or make the clip a littler longer at the front meaning it’ll snap to grid “late” (with my early note on the one).
I want to make a time selection of a bar which contains early notes as I’ve been describing: I end up needing to include a short time before the 1 in my selection to accommodate, potentially taking little snippets of other clips.
My general thinking is 2 fold
I think I’d like recording to occur during the preroll and the playback of that preroll to be included in the clip prior to the part that snaps (like a fade in), but not be just of the clip loop.
I’d like a “forgiveness” or “affinity” parameter such that notes played just prior to a musical beat (or extending just into another bar) be associated with the bar they were “intend” to be played in. This means if I snap a clip to grid which has a preroll note played 5ms early, the note remains 5ms before the clip start, even when clipping. This could also apply to time based selections to avoid you cutting off a small sliver of a note at the start of end of a selection when you recorded unquantized.
Anyway, these are my thoughts, but I wanted to get an idea of what people thought about the problem itself and my proposed solution, and if anyone else has any other ideas or better fixes to propose.
Regarding the general feature, I would not want notes that weren’t visible in the arranger to play, instead what I imagine are “ghosted ears” either side of the clip. These regions would be semi transparent and contain notes that fall outside of the beat aligned recording region (primarily recording during count in, or held after recording ended). When moving the clip, it would snap to the edges of the “clip proper” but the early notes would protrude ahead of, or behind. This region would be allowed to extend before the 1 on the timeline into negative time. When recording, they would play during the count in to the one; during regular playback, the track start would be bar 0 vs bar 1 to accommodate them. My expectation is also that these early notes would only play at the very start or end if the clip were looped in the arranger.
In the latter case, I’m talking primarily about selection on the timeline in unquantized recordings. Imagine I played a note that should logically occur on the 1 of bar 2; Instead I played it on the 4.99 of bar 1. If I make a time wise selection starting at bar 2, I logically want that to include the note I’m referring to. Instead I’d like my selection to realize that the note I played early is associated with my time selection: this is what I refer to as affinity of the note. In the current design, my time selection could cut that note taking the majority of it with the bar but leaving a tiny sliver of it which came before the selection.
These problems all occur with unquantized recordings, but also if you apply humanization with quantization. A note on the 1 at the start of a clip can be shifted forward such that it no longer plays. These type of features could avoid that problem by consider such notes as retaining an affinity with the bar within which they are played.
I know one related feature which MPCs have. You can request that any notes played in the preroll get recorded on the 1. This doesn’t accommodate musical situations where notes should play during the preroll, but it does mean you can play a note on the 1 fractionally early, while recording, without losing it (it not being recorded).
I think a common partial human solution is to consider the second bar as the start of the song. I believe Ableton has an option to record during the preroll, meaning extra notes are there, but considered as lying beyond the clip boundary. You can extend the clip extents, once recorded, to make them visible and have them play.
I do use Note Chase, though that’s primarily for long notes like droning, or extended chordal elements. Note Chase will not play the note early but rather, it will play the part of the note that’s in the bar. Those means an early note will play back exactly on the 1, but a late note will play as recorded.
Can this be related to the fact that MPCs support MIDI capture?
If you get some sound coming from a note not included in the clip, then (I guess) Bitwig needs to play that MIDI internally somehow, it cannot just produce the sound “left” by the time the clip starts. Maybe we could move this discussion to Drafts and then link this request with MIDI capture?
Still about the MPCs (I have an MPC One btw, hi) another factor to consider is that very often notes trigger samples, not the sound produced by an instrument. Technically this is a very different problem, I believe, because rendering a piece of audio at a given time can be dine without having to play the sample from the beginning.
In other words, have you tested whether this MPC feature works for their synths too and not just for samples?
Just realized this is pretty similar to my brainstrom post Cliplauncher and Starting on an Upbeat - Brainstorm - Bitwish
And as Icaria36 pointed out the Audio pre record feature request is also kinda the same.
(Don’t know about that legato post)
I think your “forgiveness” or “affinity” parameter" could also be the same feature, just with a very small “preroll”.
So together it would be a feature that includes:
a preroll-time"-clip-property. This will activate the content in the negative timeline of the clip.
automatic recording in the negative time
Snapping points and launch quantization reference points remaining at the first beat (non negative) of the clip.
This would solve my launch Q problem, all problems your described and the Audi Pre Record feature.
@icaria36 I would delete my post and move it here, but there is already an answer there. Can you move both over here?
I can’t find the right English word, maybe somebody can help me out. I am talking about when a phrase starts not on the first beat of the first bar but instead somewhere in the bar before the start.
an “Auftakt” in German, I find nothing better than “upbeat” on google but am not sure if that is right.
So this is what I mean with an “upbeat” here.
The Problem
Upbeats are a big problem for the cliplauncher, especially vocal phrase often start before the actual loop they’re in. Just starting them with launch quantization on the first beat will thus result in this part missing. Effectively making them unusable when using Clip Launcher + Launch Quantization (Launch Q).
Workaround
Having a Clip with just the upbeat that plays the normal clips with the “next action”. This works, but requires the double amount of clips, and one has to manually start the clip a whole launch Q cycle earlier, resulting in a clunky workflow and UI.
Brainstorm Solution.
Allowing clips to have content before the first beat (in the negative timing). Then, if they are started using launch quantization, the clip will actually be started before the launch Q point, such that the upbeat is played before the launch Q point and the “first beat” of the clip will be correctly placed on the launch Q point.
I think this would work and would be a good solution, but it has some flaws.
It is kinda unintuitive and weird, that clips will play earlier than a simple look at the launch Q suggest, but I think this would be ok.
It depends on how exactly Bitwig is implemented, but I’d guess the launch Q is implemented pretty deep and thus such a change might be complicated to implement.
So does anybody have a better idea to fix this problem?
well, you can define clip start before the loop, so perhaps you can make offset start for all clips that need to start and loop later than your vocal clip
Thats a neat workaround idea!
It’s still kinda weird, since this would mean I start all my clips one launch Q cycle early, but I can start them all at the same time with this. Thats quite an improvement.
Thanks! Will probably use this workaround until something new is implemented.
another factor to consider is that very often notes trigger samples, not the sound produced by an instrument. Technically this is a very different problem, I believe, because rendering a piece of audio at a given time can be dine without having to play the sample from the beginning.