Delay Compensation

[takaii]

Dom just read it!

I wanna say that track delay when using earlier will create latency for the other tracks like you wrote! But its exactly what makes it so beatiful!

It makes it possible to play clap or snare or hihat transient before and after another kind of transient precussion or a kick.

I know you are against it because of latency! But listen to audience instead! Latency is not an issue because its excpected when using track latency. Its an solution for not having to shift the clip itself.



DOM if i did this manual i would have to select all tracks, shift position to start on bar 2 instead and make a clip start before and after kick and moving around so it id not exluded. So the content would actually be played before everything else as well.

Only difference is that it adds latency to other tracks but if doing pre shift. But that is the point man! I cant belive you see something bad when no one else do. If people dont like to use it they wouldnt use it either.

For so many people there is no better solution and that you actually are afraid off certain excpected latency is to be excpected.

Is this the same reason you dont have a linear phase eq? Even limiter introduce latency! Dont run because of latency seriously. I am a bot disopointed to see this is the resolve of the bitwig team... Sry to say that but its soo great future that you would have to look past latency just like with linear phase eq and limiters and stuff.

[dom@bitwig]

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.
However, did you read this?

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

[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.
However, did you read this?

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

Yes i saw that. Well it might be true that people might not understand that at first. But then its only logic it will. Its still agreat feature. But a device makes is chunky. Its much better how ableton did

[Andrei Marchenko]

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..
Cheers,
Dom

This! For sure \m/

[takaii]

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..
Cheers,
Dom

This! For sure \m/

Want me to tell what is so negative about a device?

Let me say you put in 3 snares on 3 different tracks. You want to shift forward and backwards to
shift the transient and the entire sample to play before or after.

YES GREAT

BUT... then you realise how slow it is by going into each tracks devicepanel to shift the tracks. You also need to go back and forth to get a good result also
That way it would be slow and work against workflow when the same thing could be implemented on each track.

If its that you dont want negative stuff from new users not used to this why not for first time we press the D icon it comes up a warning message and warning messages can be turned off in preferences saying that
Before using track delay beware that it creates Latency to other tracks to be able to delay a track or shift.

[takaii]

Totally ok if you like that approach more, takaii, we just have a different experience when it comes to user reports regarding the track delay parameter and therefore a different opinion on how to solve it.

I'm just a tiny bit surprised because you said yesterday, for example, that object snap being on as default confuses people if they don't know it and is the most annoying thing in Bitwig Studio. But there it is also only logical that it snaps to objects...

However, to sum it up again and close the topic: Currently the decision is not to make it a track parameter but we might add the functionality via a device.

Cheers,
Dom

Well the thing is that track delay is not something you use without opening it up. Just like A B feature that i never used. But object to snapping is on by default even if you dont want to use it that is a difference.


but i rest my case now Dom i will trust you guys probably wont listen to this and i dont wana argue to much. its not just about me and my opinion even if make it seem like that. I wana help and give ideas and sometimes i am a bit to much forward kind of guy.

[dom@bitwig]

Totally ok if you like that approach more, takaii, we just have a different experience when it comes to user reports regarding the track delay parameter and therefore a different opinion on how to solve it.

I'm just a tiny bit surprised because you said yesterday, for example, that object snap being on as default confuses people if they don't know it and is the most annoying thing in Bitwig Studio. But there it is also only logical that it snaps to objects...

However, to sum it up again and close the topic: Currently the decision is not to make it a track parameter but we might add the functionality via a device.

Cheers,
Dom

[dom@bitwig]

But object to snapping is on by default even if you dont want to use it that is a difference.

Nope, not anymore. We just changed that in 1.3.4 RC 1 yesterday to avoid confusion.

Cheers,
Dom

[takaii]

[codec17]

But object to snapping is on by default even if you dont want to use it that is a difference.

Nope, not anymore. We just changed that in 1.3.4 RC 1 yesterday to avoid confusion.

Cheers,
Dom

Not so happy about this one..
But ey.... Just need to keep an eye on it...
BUT! When does hardware bitwig helmet come that convert my musical thoughts ???
Need it! NOW! Want it NOW!... Can i live without? .... well ok.... yes.

[takaii]

But object to snapping is on by default even if you dont want to use it that is a difference.

Nope, not anymore. We just changed that in 1.3.4 RC 1 yesterday to avoid confusion.

Cheers,
Dom

Not so happy about this one..
But ey.... Just need to keep an eye on it...
BUT! When does hardware bitwig helmet come that convert my musical thoughts ???
Need it! NOW! Want it NOW!... Can i live without? .... well ok.... yes.

Ive noticed you can change and then save as template also if that helps ^^

[codec17]

@ takaii .. yes noticed it.. thnx anyhow.

[takaii]

@ takaii .. yes noticed it.. thnx anyhow.

[drakmaniso]

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.

[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 But but dom has his thought and mind set allready that it will affect new users bad =( I allready argued done with him i cant change what he thinks.Hhe knows more than me but i love ableton track delay

I love your idea man. That making a clip play beforehand instead of introducing latency! Sure the first clap on bar 1 that is shifted will be cut because it plays to early. but a solution to that would be to be able to play the track before bar 1 if anyone actually used that.