Delay Compensation

Official support for: bitwig.com
duncaaan
KVRer
6 posts since 20 Mar, 2005

Post Tue Mar 10, 2015 6:36 am

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! :)

User avatar
irre
KVRAF
4419 posts since 21 Jan, 2008 from oO

Re: Delay Compensation

Post Tue Mar 10, 2015 6:51 am

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

duncaaan
KVRer
6 posts since 20 Mar, 2005

Re: Delay Compensation

Post Tue Mar 10, 2015 7:53 am

Will do. Thanks for the heads up.

Cheers

User avatar
dom@bitwig
KVRian
912 posts since 1 Nov, 2012 from Berlin

Re: Delay Compensation

Post Tue Mar 10, 2015 8:03 am

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
KVRian
588 posts since 26 Mar, 2014 from Denver, Co

Re: Delay Compensation

Post Tue Mar 10, 2015 8:44 am

It's cool guys all you have to do is be a genius and offset your regions by a few samples.
• Studio One 3.2.2
• OS X El Capitan 10.11.3
• Mac Pro (Late 2013)
• 2.7 GHz 12-Core Intel Xeon E5
• 64 GB 1866 MHz DDR3 ECC
• 2x Daisy-Chained Universal Audio Apollo Quads

- Olley Ollet

Hez
KVRian
647 posts since 10 Dec, 2013

Re: Delay Compensation

Post Tue Mar 10, 2015 1:55 pm

dom@bitwig wrote: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?

User avatar
irre
KVRAF
4419 posts since 21 Jan, 2008 from oO

Re: Delay Compensation

Post Tue Mar 10, 2015 2:25 pm

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

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

User avatar
u-u-u
KVRian
970 posts since 31 Mar, 2014

Re: Delay Compensation

Post Tue Mar 10, 2015 3:54 pm

dom@bitwig wrote: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
KVRist
38 posts since 19 Oct, 2011

Re: Delay Compensation

Post Tue Mar 10, 2015 5:50 pm

u-u-u wrote:
dom@bitwig wrote: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
KVRist
215 posts since 25 Aug, 2006

Re: Delay Compensation

Post Wed Mar 11, 2015 4:34 am

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.
Logic X, El Cap 10.11.3, Mini i7, Live, Reaper, Bitwig (demo)

Clicks at +100 samples: 44.1k / 48k (wav)

User avatar
dom@bitwig
KVRian
912 posts since 1 Nov, 2012 from Berlin

Re: Delay Compensation

Post Wed Mar 11, 2015 4:38 am

Hez wrote:
- 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
Banned
1601 posts since 29 Sep, 2014 from Halmstad, Sweden

Re: Delay Compensation

Post Wed Mar 11, 2015 4:51 am

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
desktop: windows 10 x64, i5 4690k, 32gb ram 1600mhz, 2x ssd 128 gb +2x3 tb, asus gtx 970, asus proz gamer motherboard, no external audiocard
laptop: windows 10 x64, i7 mq4700, 12gb ram 1600mhz, 1 tb, asus gt 750

Hez
KVRian
647 posts since 10 Dec, 2013

Re: Delay Compensation

Post Wed Mar 11, 2015 5:05 am

dom@bitwig wrote:
Hez wrote:
- 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.

User avatar
dom@bitwig
KVRian
912 posts since 1 Nov, 2012 from Berlin

Re: Delay Compensation

Post Wed Mar 11, 2015 5:19 am

ronnyrydgren wrote: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

User avatar
dom@bitwig
KVRian
912 posts since 1 Nov, 2012 from Berlin

Re: Delay Compensation

Post Wed Mar 11, 2015 5:31 am

Hez wrote:[
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

Return to “Bitwig”