Delay Compensation

[Cyoon]

well, the benefits of a native device should be obvious, audio rate timing.

[owensands]

well, the benefits of a native device should be obvious, audio rate timing.

Cant use LFO modulator to change a delay time in 3rd party plugin? Or am I missing your point? You meaning getting offsets that are lower then 1ms of a delay plugin?

[Cyoon]

well, the native device would react better in timing as far as i know, since itself is modulatable in audio rate. Wich a 3rd party plug isn't.

[u-u-u]

well, the native device would react better in timing as far as i know, since itself is modulatable in audio rate. Wich a 3rd party plug isn't.

As I understand it, both solutions - the plugin and the native device - cannot be automatable. That's also the reason why the delay values on the Hardware FX and Instrument aren't automatable.
As Dom already explained: when setting it to a negative delay it reports this value to the PDC system which then will delay all other channels.
And now imagine you also have this device on other channels and automate the delay time. I think that would create total mess and lead to audible artifacts.

[Cyoon]

and lead to audible artifacts.

hehe, as long as we can sample them i'd be fine
No seriously, this position attributes should give us the clear values about time

that would be enough i think..e

[u-u-u]

Sry for writing so much but just another thought:
In a live band it is also more like delaying things backward rather than forward. A (good) bass player often plays a bit later than the drums. Same goes for pianists (and probably for all others). So maybe it might be a good practice to get used to shift things back in time to leave space for other things.

and lead to audible artifacts.

hehe, as long as we can sample them i'd be fine

Did you already try youtube with a bad internet connection?

[Cyoon]

not yet but can you suply a record of it? would be cool..

[shadiradio]

I'd also like to throw my support in for a simple native device that allows you to delay (positively or negatively) a track in BWS. I used to track delay feature of Live *all the time* to adjust the relative positions of slow sample instruments (like ostinato strings so the peaks land right on the beat, etc). Slow string passages are great on their own, but when mixing orchestral + electronic, it's very beneficial to have timing features so everyone's locked in. In Bitwig I've been shifting the notes by ticks, but as others have mentioned this can get messy. One issue is that the first note in a clip will be cut off because it now begins outside the clip's starting edge. You can extend the edge, but if this needs to bump up against another clip preceding it, you just get some editing annoyances that build up over time. It's easy to forget to turn off relative snapping when moving chunks around, and later on you'll see tiny edges gone, etc, and be like "oh yeah! it's because of that delayed track."

Initially I was thinking a track delay number in the inspector would work, but since it is probably a less common feature, I like Dom's idea of just a simple device you can drop in the track. It's usually a one to two track exception for me, rather than something applied to most tracks.

To be fair, I used the track delay feature in Live to compensate for its own lack of compensation (PDC and automation) - that is, I would have to change my track delay numbers in Live periodically while working on a project because of its wacky timing issues that were ever-changing depending on what you were doing.

[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

TBH.. I would stick to this and implement it (musical offsets / pre-delay, not PDC) via event->deltaFrames or whatever equivalent in Bitwig. Per-event and optionally (option per device) handling live events not to be delayed is just better on the long term. Not saying the GUI can't be a device that looks like a simple delay, but having unavoidable latency in live context just because you want a track offset.. don't know. Seems wrong. For PDC it's clear that the plug-in can't respond earlier. But for those offsets this is not the case.

[InsidePeople]

Another thing i can imagine us doing even before would be a Bitwig device that you actually insert into the chain that gives you a positive as well as negative delay parameter and it reports latency, so that it shows up in the latency readout just as a delay introducing VST would do. This way people would be more aware about the latency they're introducing this way.

Cheers,
Dom

This seems like a clean solution as long as it supports negative offset. Bonus for variable time units: samples, ms, meter.

I would like to +1 the need for this feature. I feel very strongly about this. It is critical to easily tweak microtiming in what is fundamentally a time-domain tool.

I respect the need to keep things simple, but it's really hard to beat the simplicity of the user experience of grabbing a slider and tweaking a track globally until it "feels" right. I use this in every single Ableton project I've ever done.

[Ogopogo]

You could slap that right in the "tool" device. While you're changing the gain knob so it goes down to zero.

[Ch00rD]

While you're changing the gain knob so it goes down to minus infinity.

FTFY.

[slackhead]

This seems like a clean solution as long as it supports negative offset. Bonus for variable time units: samples, ms, meter.

I would like to +1 the need for this feature. I feel very strongly about this. It is critical to easily tweak microtiming in what is fundamentally a time-domain tool.

I respect the need to keep things simple, but it's really hard to beat the simplicity of the user experience of grabbing a slider and tweaking a track globally until it "feels" right. I use this in every single Ableton project I've ever done.

Being able to rush or drag a specific part can make a massive difference to rhythm programming. I was doing this in Cubase over 20 years ago - it should be standard basic stuff by now.

[GhostPlayer]

Sometimes, all you need is good nudge to get the feel right. Though I absolutely need proper DC tools, way too often I find that manually offsetting by ear gives me much better results, even if not mathematically perfect. Depends on the source material really. But yeah, even kicks can benefit massively if you don't look at the numbers or grid alignments.

Yesteryear's Cubase fat kick layering was all about about that. Still is for the veterans

[PHY6]

Another thing i can imagine us doing even before would be a Bitwig device that you actually insert into the chain that gives you a positive as well as negative delay parameter and it reports latency, so that it shows up in the latency readout just as a delay introducing VST would do. This way people would be more aware about the latency they're introducing this way.

Cheers,
Dom

This seems like a clean solution as long as it supports negative offset. Bonus for variable time units: samples, ms, meter.

I would like to +1 the need for this feature. I feel very strongly about this. It is critical to easily tweak microtiming in what is fundamentally a time-domain tool.

I respect the need to keep things simple, but it's really hard to beat the simplicity of the user experience of grabbing a slider and tweaking a track globally until it "feels" right. I use this in every single Ableton project I've ever done.

Yeah, a function that moves all notes forward/backwards (nudge) in samples would be very usefull, and will not interfere with the PDC