Delay Compensation

[u-u-u]

It is an issue, as most people don't realise that they introduce latency to their project by doing so.
Therefore it will most likely not become a track property in Bitwig Studio.

And what about shifting the logical timing of events, rather than the resulting audio stream (i.e. scheduling all clips of a track with a positive or negative offset)? This doesn't introduce any latency, and achieve mostly the same result.

I know we can already do this manually in the arranger, but it's extremely inconvenient, and impossible in the clip launcher.

What i said Also i think a device is also very inconvenient because you need to go into a chain to change values. And i dont need more devices in my chain XD

Thing is, it probably is better to have it as a device because latency seems to be handled on a device chain base in Bitwig Studio. That requires a little bit of thinking and might not be as obvious for newcomers. But I guess (don't know of course) in the end a delay device would enable us to shift the time of individual FX layers, not only whole tracks. And that'd be even more flexible than in Live.

[takaii]

It is an issue, as most people don't realise that they introduce latency to their project by doing so.
Therefore it will most likely not become a track property in Bitwig Studio.

And what about shifting the logical timing of events, rather than the resulting audio stream (i.e. scheduling all clips of a track with a positive or negative offset)? This doesn't introduce any latency, and achieve mostly the same result.

I know we can already do this manually in the arranger, but it's extremely inconvenient, and impossible in the clip launcher.

What i said Also i think a device is also very inconvenient because you need to go into a chain to change values. And i dont need more devices in my chain XD

Thing is, it probably is better to have it as a device because latency seems to be handled on a device chain base in Bitwig Studio. That requires a little bit of thinking and might not be as obvious for newcomers. But I guess (don't know of course) in the end a delay device would enable us to shift the time of individual FX layers, not only whole tracks. And that'd be even more flexible than in Live.

You can use a normal delay for that. But can it even be possible to use thid device in mind to get a reverb to play before the dry signal? Would be cool if that is possible

[drakmaniso]

Thing is, it probably is better to have it as a device because latency seems to be handled on a device chain base in Bitwig Studio.

Except that a track offset feature must not introduce latency: it should shift the timing of events (i.e. when clips are scheduled), not the audio stream itself. This how it's done in most of the DAWs I used, and even in some hardware sequencers. This approach covers the most important use cases.

The device approach can only add latency, so this is one feature that have to be implemented directly in the DAW.

[takaii]

Thing is, it probably is better to have it as a device because latency seems to be handled on a device chain base in Bitwig Studio.

Except that a track offset feature must not introduce latency: it should shift the timing of events (i.e. when clips are scheduled), not the audio stream itself. This how it's done in most of the DAWs I used, and even in some hardware sequencers. This approach covers the most important use cases.

The device approach can only add latency, so this is one feature that have to be implemented directly in the DAW.

I like your way much more the devs. Should hire you !

[dom@bitwig]

This does not work.
Imagine pre-delaying an event to play 100msec before the actual 1.1.1 of a project.
Playing that project then means you have 100msec latency between hitting space and hearing 1.1.1, else you would not hear the pre-delayed event, no way around that without time travel.

Also, the statement that the device approach only being able to add latency in one direction is wrong, it allows for positive as well as negative delays.

Cheers,
Dom

[drakmaniso]

This does not work.
Imagine pre-delaying an event to play 100msec before the actual 1.1.1 of a project.

With all due respect, yes it does, and some other DAWs and sequencers use that approach (I know for sure that the old hardware Yamaha Rm1x did, and either Ardour or Rosegarden; my memory is a little fuzzy about the others).

Your example is a corner case (starting playback right on a note with negative offset), and as such it's acceptable if it doesn't behave perfectly (e.g. cut the start of the midi note or the audio).

The only other corner case is probably in the clip launcher, when the user schedule a clip just before the quantized start time, but after the offset time. But in practice, musicians instinctively know that they must start a sound with very slow attack a bit earlier (as well as any "flam" or "grace" notes); so if they are late, it won't be a surprise if the clip is cut or scheduled for the next quantization.

For all other cases it works as intended. And as long as you keep the offset within reasonable bounds, the corner cases should never be problematic.

As for the device approach, I'm aware that it works in both direction, what I was referring to is the fact that it can achieve negative delay only by adding latency to the whole project, which is a problem. That's why track offset should be a DAW feature, it's the only way to avoid latency in all cases. It also solves the problem of recording vs playing midi clips, which is problematic for the device approach (I don't want to apply any offset to the notes I play live).

[dom@bitwig]

That's exactly why it is the wrong approach for non-linear sequencers.
For linear sequencers, that only play a predefined arrangement, living with the few downsides (very beginning of a project etc.) that results by moving the events timing within the clip structure might be ok. For a non-linear realtime DAW this beginning-of-project problem exists for every clip launcher action, as you do those in realtime instead of knowing what happens way before (arrangement). Same in Live, where it creates latency using the track delay, but can't mess with the timing itself to not break the session view.

Cheers,
Dom

[owensands]

This does not work.
Imagine pre-delaying an event to play 100msec before the actual 1.1.1 of a project.
Playing that project then means you have 100msec latency between hitting space and hearing 1.1.1, else you would not hear the pre-delayed event, no way around that without time travel.

Also, the statement that the device approach only being able to add latency in one direction is wrong, it allows for positive as well as negative delays.

Cheers,
Dom

Isn't that what the hardware instrument latency does though? If you have negative latency and something at 1.1.1 then it starts the tracks with the lowest negative latency and everything else starts AFTER that by the offsets no?

Also I personally don't really need this as I just move audio inside the clips by a few samples and it seems to work great and it stays in tact in the arranger when I keep the shifts in the clip containers.

[drakmaniso]

IMHO this is a false problem, as most uses of negative offset are probably around or below 50 ms (i.e., compensate for a slow attack, and flam/grace notes). The chance that the user triggers a clip less than 50 ms before the desired start is very low, and if the clip is then scheduled for the next quantization the user will probably think they missed the beat.

I really hope that this will be reconsidered at one point, because having to add latency to a whole project just to tweak the timing of a sound is a huge price to pay for such a common feature. As for the workarounds, shifting midi clips manually is not possible in the launcher, and shifting notes makes midi editing really cumbersome.

Anyway, thanks for taking the time to answers in detail!

[dom@bitwig]

@Owensands: Yes, exactly, a track delay function (be it implemented as a device or as a track delay field as in Live - technically the same) always adds latency to the playback of the whole project. The other solution that drakmaniso proposed and that other linear DAWs use, is exactly what you do manually, which to me is also exactly the right thing to do. But this just can't be applied automatically in case of a non-linear daw, as it would mess up the clip launcher functionality.

Cheers,
Dom

[takaii]

@Owensands: Yes, exactly, a track delay function (be it implemented as a device or as a track delay field as in Live - technically the same) always adds latency to the playback of the whole project. The other solution that drakmaniso proposed and that other linear DAWs use, is exactly what you do manually, which to me is also exactly the right thing to do. But this just can't be applied automatically in case of a non-linear daw, as it would mess up the clip launcher functionality.

Cheers,
Dom

Using a device is worse for such simple tricks making a bad workflow for it. Going into device chain of each track

[takaii]

This do Not work for me owensand as i want to shift claps before the kick example
It only cuts the audio out if i want the clip in line.

Check audio editor at bottom i was shifting. Simply do not work this way

NO SOLUTION. For you YES. For the trick i do. BIG NO!

1.png

[dom@bitwig]

As explained in length now, using global track delays to just move the timing of notes in front of others is not the right solution and bad workflow in general - that's why we don't add it to the tracks.

If you want to nudge notes in front of others, enter track edit (instead cip edit) and move the timing of the notes themselfes instead of messing with the project's pdc using a track delay. That's why there are features like track edit or relative snap, that even makes it possible to snap notes that have a slight offset

Cheers,
Dom

[takaii]

As explained in length now, using global track delays to just move the timing of notes in front of others is not the right solution and bad workflow in general - that's why we don't add it to the tracks.

If you want to nudge notes in front of others, enter track edit (instead cip edit) and move the timing of the notes themselfes instead of messing with the project's pdc using a track delay. That's why there are features like track edit or relative snap, that even makes it possible to snap notes that have a slight offset

Cheers,
Dom

If its bad workflow how come so many think its great... The argued against it except you guys is from people who have their way of working or dont shift clips. For me and many it enhances workflow. Dont like this way dont use it not harder than that. It wont be shifted by default

[drakmaniso]

That's why there are features like track edit or relative snap, that even makes it possible to snap notes that have a slight offset

...but makes it really cumbersome to enter new notes, as you have to remember to always duplicate an existing note.

It also doesn't solve the "note at clip start problem". In fact in the current implementation it's even worse, afaik when you shift those notes slightly before the beat they are never triggered. You have to add silence in front of the clip and change the loop start, but then it can make triggering the clip (in the launcher) really challenging.

I really don't see how this solution is better than the one I describe... From what I see, the current one have disadvantages that are always there, whereas the other only have a few corner cases.