Delay Compensation

[takaii]

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.

Its a few people who thinks its better. Many love what we want but they somehow are locked on their opinion rather than what so many in this forum like Nothing to do really they set their mind up a long time agoo. They have bad thoughts about it but people in general love stuff like this that makes it so easie to shift clips.

[takaii]

http://www.kvraudio.com/forum/viewtopic ... 9&t=452079

Another who needs track delay! Dom Sry to still talk about this. I wana say A and B feature fader in bitwig is also an feature that is misstunderstood and its implemented in bitwig. It does not help me with arranging since i feel it useless really. But i dont complain about it anyway. If someone doesnt want track delay they probably wont use it. If someone want to delay something on their live music even an device is a bad idea. It is like talking against yourself saying we should not have track delay. Making a device is worse because think of an limitless chain of plugins with small things that replaces normal functions. AAAAND you still have latency problem. Why not add latency information to each track in mixer tracks with peak value and all. That way people wont get confused off it adding latency.

Please add it to the tracks that can be hidden with the icon among the others like hide/show effect tracks, hide/show disabled tracks, /hide show track cross fade, hide/show send effect amount knobs. Have it hidden like default just like track crossfades. This way people who use it will use it. And if they are confused they see latency add to their mixertracks.

A device is a really bad workflow killer since you go into a chain, look up the plugin and then change it then go to next track into device chain. When you could just side by side just switching like in Ableton.

I and others really really want this i dont see no limit for it actually. A device have same bad purpose as you talked about. The idea of letting it show latency could be implemented in the tracks as well also when having track delay open side by side.

Like when draggin value negative, instead of showing it negative it could add postive to all other tracks right? this way no confusion. Soo i add drag backwards to add on clap to add latency to all other tracks, then the other tracks get the ms + instead and clap has 0. This way No one will ever be confused. So the one track that has most negative value will instead be 0ms shifted. This way it gives an picture of whats really going on

[Kung VU]

Like when draggin value negative, instead of showing it negative it could add postive to all other tracks right? this way no confusion. Soo i add drag backwards to add on clap to add latency to all other tracks, then the other tracks get the ms + instead and clap has 0. This way No one will ever be confused. So the one track that has most negative value will instead be 0ms shifted. This way it gives an picture whats really going on

I think that could be a pretty good solution. I imagine a lot of people will first be surprised to see all the other tracks to go into positive values by dragging that track into negative values, but that will have a very educating effect on these peoples minds. Everybody will be aware of the added latency. But I think the thing missing here is that the live triggered clip launcher still will be messed up if I understood Doms concerns right.
At this point of the conversation I think the developers are aware that a ton of people really would like to have a track delay feature. Let's give them some time to think how ist maybe could be done. Who knows maybe they indeed invent a time machine…

[pdxindy]

Track Delay in Live is a valuable/useful feature...

[bleepbot]

I have a suggestion that should make everyone happy.
So the main argument against a delay device is not being able to directly change it in the mixer.
Why not have a slider or similar control, directly on the item in the chain displayed in the mixer?
That way it would be accessible without navigating.
Now if you want to adjust the GUI that way is the question, but it's the only real compromise I can think of.

[takaii]

I have a suggestion that should make everyone happy.
So the main argument against a delay device is not being able to directly change it in the mixer.
Why not have a slider or similar control, directly on the item in the chain displayed in the mixer?
That way it would be accessible without navigating.
Now if you want to adjust the GUI that way is the question, but it's the only real compromise I can think of.

The main argumet against a device is =workflow killer. Having to go into a device and look up plugin, or add via browser and copy to other tracks etc etc. Back and forth back and forth for setting it up.

Having it like ableton +1000 betrer workflow. Its their on each track. No jumping arround, easy access. I dont see why not. Bitwigs argument is that it adds delay. What i dont understand is how does having a device instead not adding delay also? So the argument to have a device instead of track delay becomes invalid because they both add latency. Saying we cant make track delay because it adds latency and that would be bad for live play is same for device because it adds delay and would be bad for live play. The only benifit with a device is that it could e set in another device wet fx. But to add delay negative or positive directly on the tracks it is a huge workflow enhancer compaired to a device when wanting to shift tracks.

I can se a point having both? but not having track delay because it adds latency as statement and then saying another solution which has worse workflow for same thing, and it also adds latency. its a big WTF

[TeePee]

What i dont understand is how does having a device instead not adding delay also?

It does add (PDC) delay.

As you said, they both do the same thing. Delay other audio routes by creating latency.

One method is clunky as hell though.

[takaii]

What i dont understand is how does having a device instead not adding delay also?

It does add (PDC) delay.

As you said, they both do the same thing. Delay other audio routes by creating latency.

One method is clunky as hell though.

Yep thats what i mean XD
Dom doesn't like track delay because it adds latency and that could ruin live playing. He suggested a device which add exact same PDC delay. The issue isnt latency, its people who is not using it for the right thing, track delay shouldnt be used for live playing. Its an awesome feature for creating music with. A device will slow down workflow compaired to having track delay like ableton. Both features are no good for live playing. People who use it for live is equally easy to wrongly use as any other feature when knowledge is not there. So not having track delay because of missusage of knowledge is not an excuse not including it in bitwig. I hope they come to their senses.

Not all people use track delay or dont have the knowledge how it benifits workflow and phase and all or creativity. We are many who wants this feature. Yet they insist not adding it BUT adding a horrible idea with device. Sure bring both to us, i would love have pdc on reverb fx. But it should not be a replacement for Track delay. Jumpin around in device chains is no good

[Andrei Marchenko]

In-build device for PDC is more than nothing For me it's a on of my top features for production. And i cross my fingers ^_^

[takaii]

In-build device for PDC is more than nothing For me it's a on of my top features for production. And i cross my fingers ^_^

its more then nothing but worse then track pdc delay. Why be happy with next best thing if bitwig could implement the best thing? its up to them and its not really a no go to do track delay, they just decided it like that, but i hope they choose track delay instead. I dont want next beest when i can have more than that. Please devs!! Change mind

[TeePee]

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.

Yes, but, as intended, the track with the -100ms track delay will sound 100ms earlier than 1.1.1. So, in fact you haven't waited any additional time to hear a sound, because the track with the -100ms track delay is heard first, without delay, as intended.

(Ok, let's use that 100ms figure you plucked from the air. I've never used a negative track delay higher than -40ms ..)

So, in other words, if I pre delay a track to play 100ms early, it's because I want it to sound 100ms before 1.1.1. That's the whole point!

... no way around that without time travel.

It's got nothing to do with time travel. It's about RELATIVE TIMING from a sequencer. Placing a sound early or late, relative to Bitwig's timing grid.

Let’s say I need 100ms of negative track delay for software monitoring an external synth. That 100ms consists of the audio roundtrip (because I must be using a humungous buffer size!), MIDI output latency, and response time latency from my synth.

The best solution is to pre-schedule the MIDI to happen early, relative to the grid, which would cause 100ms of silence immediately after hitting the space bar. No-one would notice the pause/silence because it's only 1/10th of a second! I definitely don't notice it in Logic, where my track delays have a more realistic figure of around -12ms.

And, unlike your solution, 100ms after hitting the spacebar, that 100ms of pre-roll latency is completely removed from the user. As far as the user is concerned, that 100ms of latency no longer exists after the pre-roll. Also, live MIDI input is simply treated as real-time and sent as soon as it is received - that’s how Logic does it. This is why in Logic I can play a scheduled MIDI clip to an external synth and simultaneously play live MIDI over the top, without the burden of that 100ms of PDC latency.

Your solution is to rely on the PDC system, which means your 100ms of latency is a burden throughout the whole duration of a song - a constant 100ms latency burden. It would help if you provided a "Reduced Latency When Monitoring" option, like Ableton, that's bypasses PDC delays for live monitored tracks.

So, your solution burdens the user with the latency all the time. With the *pre-roll* or MIDI pre-scheduling method, 100ms after hitting the spacebar, the pre-scheduling latency has been compensated for and removed from the user, and is no longer a burden to the live keyboard player.

[TeePee]

Double.

[takaii]

TeePee there is no issue with PDC. Only for live purpose. Which its not meant to be for. There is no way around PDC delay with track delay. Just add track delay rather than a device. People love this feature, some though have gotten it wrong, like they have done for ages. like some people think mastering will fix a bad recording or songwriting. Or that a bad recording can sound professional mixed. People do misstakes all the time and i dont think bitwig should try to douge a bullet because some people dont get the idea of PDC delay.

[TeePee]

TeePee there is no issue with PDC.

If you mean it looks like we're stuck with the PDC solution, then sadly I have that feeling too. And if we are stuck with this inferior solution, a "Reduced Latency When Monitoring" type option is vital for live keyboard play.

But if you're saying the PDC system is necessary for track delays..

There is no way around PDC delay with track delay.

.. then I'd say Logic does not create latency in it's PDC system for it's track delays. So, using a track delay or software monitoring an external synth doesn't cause latency throughout the whole system. (edit: except for a brief period immediately after hitting the spacebar)

I'm basically saying, it can be done without creating PDC latency everywhere else, and I've got Logic to prove it.

[drakmaniso]

The best solution is to pre-schedule the MIDI to happen early, relative to the grid

That's what I have been advocating earlier in this thread, but Dom replied that they don't want to choose this solution because of one corner case: when you launch a clip in the launcher, if this clip has a negative delay, events at the start of the clip, there is the possibility that the triggering action (i.e. the use clicking on the clip) happen too late for pre-scheduling. I.e. if the clip has a -200 ms offset, but the user launch it 100 ms before the bar, there is no time to pre-schedule correctly.

IMHO this should not be a problem in practice, as most useful offsets would probably be much sorter than this, and in the case of longer ones, the user can intuitively feel that they have launched the clip too late. So I hope they'll reconsider this option at some point.