Delay Compensation

[duncaaan]

Quick question. Is there a way to set delay compensation per track as in Ableton?

The reason I ask is I want to offset the cinestrings library by about 50ms as per the video below. Explanation as to why is at 11 mins in... But basically they've captured a bit of 'air' at the front which you can offset if you want to hit the beat.

http://youtu.be/yLs6oC9yj_M

Thanks!

[llze]

sadly not, please make a feature request to support(at)bitwig.com

[duncaaan]

Will do. Thanks for the heads up.

Cheers

[dom@bitwig]

Currently we decided against it, as it would create latency for all other tracks when setting up a pre-delay for a track.
Therefore and esp. in a live context it is better to change the position of the content within the track, not shifting the whole track itself in timing.

Cheers,
Dom

[qtheerearranger]

It's cool guys all you have to do is be a genius and offset your regions by a few samples.

[Hez]

Currently we decided against it, as it would create latency for all other tracks when setting up a pre-delay for a track.
Therefore and esp. in a live context it is better to change the position of the content within the track, not shifting the whole track itself in timing.

Cheers,
Dom

Sad to hear this, as I think track offset is a massively beneficial feature. The main way I used to use it was slipping e.g. a snare track backwards or forwards by a few samples at a time, listening for the point where the transient suddenly fits into the mix. Used in this method, the overall project latency is minimal (compared to e.g. the latency caused by Fabfilter Pro-L on the master, which I have in every project anyway...). Doing this with the actual track content (at least currently) is almost impossible, because off the top of my head there are only really two options:

- Move the clips by a tiny amount - this makes fluidly moving/copying clips around the timeline extremely tedious as the snap behaviour will usually overwrite the end of a previous clip, miss the start of a new clip, etc.

- Move the notes within the clip by a tiny amount - this is also tedious because if you do it towards the end of a project, once you've found the 'sweet spot' within one clip, you now need to try to repeat that offset for the notes in every other clip

In both situations, tweaking the microtiming again later in the mix (e.g. oh this snare transient needs to come even more samples earlier now that I've added a load of other percussion) means you have to repeat the entire process, discouraging experimentation. I can't understate the importance of track offset in my own productions - I used to find that many many times when I thought I needed to reach for a compressor or clipper to catch a peak, moving a track by a few samples fixed everything immediately.

Eyeballing and dragging the start of a midi note isn't the same at all, as it's literally on a sample level that transients nicely align and this is extremely difficult to achieve iteratively by repeatedly moving a note until it fits (and then trying to move all the other notes in the clip/track by the same amount).


In terms of solutions outside of track offset, perhaps an edit feature like "Offset selected notes/events" that enables you to offset all the notes/audio events within the selected clips/tracks by a number of samples or milliseconds?

[llze]

I completely agree with Hez, it's also important to me.

currently i use this one: http://www.voxengo.com/product/latencydelay/

[u-u-u]

Currently we decided against it, as it would create latency for all other tracks when setting up a pre-delay for a track.
Therefore and esp. in a live context it is better to change the position of the content within the track, not shifting the whole track itself in timing.

Cheers,
Dom

This brought me to an idea:
What about a per-track time shifting - not for the audio signal but for the track content (clips/events, automation)?

More in detail: Only the content which is already recorded/programmed/copied in get's shifted in time. Live input wouldn't get changed (human brain can do shiftings itself).
Only problem I see here: live synced gear&devices - maybe also the sync signal/time position which is reported to the outboard gear/devices of the track should get shifted, too.

I mean it can get a real pain (for the producer type of user) to shift all notes/clips by hand after inputting them. So what I mean: Maybe a track delay/shift shouldn't change the audio output but the input material(clips, audio/note events, automation, syncing?, ...?). This way other tracks wouldn't have to be time shifted.
It could just be a simple per-track ms-shift value box (as in AL). The grid in the editor/arranger for events/clips wouldn't change and the events would't even have to appear as shifted (so they still are snapped exactly to the grid while actually being shifted by the ms-parameter).

Maybe you could at least consider that (please). I think it could be an elegant solution which would save some valuable production time and won't interfere with the live functionality.
I am sure there are some other difficulties with this idea I cannot see from my point of view and might lead to some PDC desaster. Or maybe not?

[markussomething]

Currently we decided against it, as it would create latency for all other tracks when setting up a pre-delay for a track.
Therefore and esp. in a live context it is better to change the position of the content within the track, not shifting the whole track itself in timing.

Cheers,
Dom

This brought me to an idea:
What about a per-track time shifting - not for the audio signal but for the track content (clips/events, automation)?

More in detail: Only the content which is already recorded/programmed/copied in get's shifted in time. Live input wouldn't get changed (human brain can do shiftings itself).
Only problem I see here: live synced gear&devices - maybe also the sync signal/time position which is reported to the outboard gear/devices of the track should get shifted, too.

I mean it can get a real pain (for the producer type of user) to shift all notes/clips by hand after inputting them. So what I mean: Maybe a track delay/shift shouldn't change the audio output but the input material(clips, audio/note events, automation, syncing?, ...?). This way other tracks wouldn't have to be time shifted.
It could just be a simple per-track ms-shift value box (as in AL). The grid in the editor/arranger for events/clips wouldn't change and the events would't even have to appear as shifted (so they still are snapped exactly to the grid while actually being shifted by the ms-parameter).

Maybe you could at least consider that (please). I think it could be an elegant solution which would save some valuable production time and won't interfere with the live functionality.
I am sure there are some other difficulties with this idea I cannot see from my point of view and might lead to some PDC desaster. Or maybe not?

that way, just reporting different event positions, would be cool

no live/pdc-interference at all

and supporting all possible base units

more or less like this

Code: Select all

PPQ Event::getPosition()
{
	... old stuff ...
	the_final_event_position = this and that;
	... old stuff ...


	... new stuff ...
	PPQ offset = 0;
	switch(track.musicalPreDelay.baseUnit)
	{
		case None        : offset = 0;
		case Samples     : offset = calculate_PPQ_from_Samples(blah)      //     samplerate-dependent (and non-plugin-dependent)
		case Milliseconds: offset = calculate_PPQ_from_Milliseconds(blah) // non-samplerate-dependent, non-tempo-dependent
		case Beats       : offset = calculate_PPQ_from_Beats(blah)        // non-samplerate-dependent, tempo-dependent
		case Shuffle     : offset = calculate_PPQ_from_Shuffle(blah, ...) // non-samplerate-dependent, tempo-dependent, dependent on a track-static "Quantize Time" dialog
	}
	the_final_event_position += offset;



	return the_final_event_position;
}

[TeePee]

Using the PDC system for negative track delays (a la Ableton) is a bad idea anyway, so in a way it's a good decision, but (it seems) not for the right reasons. Pre-scheduling the content timing the way Logic does is the better way to go - Logic's track delays don't cause latency everywhere else the way Ableton's PDC-piggybacked track delays do.

NOT giving us a way to bi-directionally adjust track timing is an even worse idea though. It excludes me from Bitwig. My system simply doesn't work well without them.

[dom@bitwig]

- Move the clips by a tiny amount - this makes fluidly moving/copying clips around the timeline extremely tedious as the snap behaviour will usually overwrite the end of a previous clip, miss the start of a new clip, etc.

Nope, that's where our different snap modes come into play: Absolut snap (the one we all know and love), Relative snap (the interesting part for this topic: snaps - but according to the offset it had, so if you nudge it a tiny bit before the bar, it will snap again with this offset when moving) and Object snap (does not snap to the grid, but to objects (clips, notes) already existing in the editor).
The snap modes can be activated and deactivated in the bottom right corner of the arrangement or clip editors.

Cheers,
Dom

[takaii]

Dom why not have both options? Those who prefer to delay all tracks and those who prefer timeshifting clips? Just cause it adds latency to all tracks doesnt mean some doesnt like to work that way i mean everything isnt black or white, sometimes things are gray

[Hez]

- Move the clips by a tiny amount - this makes fluidly moving/copying clips around the timeline extremely tedious as the snap behaviour will usually overwrite the end of a previous clip, miss the start of a new clip, etc.

Nope, that's where our different snap modes come into play: Absolut snap (the one we all know and love), Relative snap (the interesting part for this topic: snaps - but according to the offset it had, so if you nudge it a tiny bit before the bar, it will snap again with this offset when moving) and Object snap (does not snap to the grid, but to objects (clips, notes) already existing in the editor).
The snap modes can be activated and deactivated in the bottom right corner of the arrangement or clip editors.

Cheers,
Dom

I was having a hell of a lot of trouble with relative snap early on in Bitwig's life - just tried it again and it seems to be working a lot better now, so cheers for that.

That still only addresses a small part of what I and others have said though. It definitely doesn't lend itself towards calculated and measured manipulation of sample-level timing relationships between tracks. If I wanted to move a snare sample back by one/a few sample/s at a time until it nicely aligned with the kick drum, how would I achieve that with Bitwig?

In general, a sample/ms offset device would be pretty damn handy for layering drums within a sampler or instrument layer as well.

[dom@bitwig]

Dom why not have both options? Those who prefer to delay all tracks and those who prefer timeshifting clips? Just cause it adds latency to all tracks doesnt mean some doesnt like to work that way i mean everything isnt black or white, sometimes things are gray

Because with too many options you might end up with a tool that seems to deliver everything, but does not "feel" right anymore.

Personal observation: I've used everything from mode trackers, to Cubase 1.0 on Atari to what is available today. Most notably I've been a Logic user for a decade, unbelievably powerful tool - but many years ago i discovered i'm faster, more productive and more creative with tools that offer less but more focussed options and workflows. For others, Logic might be the better choice.
The more sophisticated music software becomes, the harder it gets to make everyone happy - and if you try to hard, you end up with something that tries to do it all, but excels in nothing and nobody wants to use anymore at all.

Cheers,
Dom

[dom@bitwig]

[
In general, a sample/ms offset device would be pretty damn handy for layering drums within a sampler or instrument layer as well.

Sure, just throw a delay behind the snare and delay it - no problem. For smaller values check out the blur device. The only thing that is a problem for a linear/non-linear sequencer is the other way around, putting things ahead of time.

(Sidenote: But even if you want to do this because you know what you do, you can just grab one of those latency fixing VST that reports latency to the host, so it compensates them, without them actually causing a delay. You pre-delayed the track by doing so and all the other will have latency - it is just that we currently decided not to offer it right of the box, as i said. Most people don't want to think about PDC and just expect the quickest possible and most stable timing. With "track delays" those people often end up with huge latencies without knowing that they caused them themselves).

Cheers,
Dom