Delay Compensation

[markussomething]

may i ask, what about this:

user wants a -1 ms offset

user selects the notes

he double clicks on note property "Start"

instead of "1.1.1.00" etc he enters "-1ms"

bitwig offsets it 1ms to the left

-500samples, -2beats, +3beats, you get it

done

ps: yeah at ppq resolution only, but should be enough (?). and nobody is forced to enter +/- values, no feature drifting.

[Cyoon]

so how many ms of shift would this be?
Would be great to have a shift option based on ms for the clips then and not the whole track, or to have the timeline changeable to seconds instead of bars.

[duncaaan]

I think there are some great suggestions in this thread. I really would like to see this implemented somehow.

So going back to my original question - currently how would I achieve this in Bigwig?
It's part of the design of the library. I just want a simple way to offset the audio - without moving notes about on the timeline as this can get messy when programming rhythmically.

Cheers

[u-u-u]

For all those who just want to shift all the notes of a track shift backward to make transients fit:
Use this time value to shift the whole clip like Suloo shows in the upper post.
In the detail editor it looks like this:

Shifted clip.PNG

For adding/editing notes switch to the clip content editing mode and voilá: everything will appear on the grid and you don't have to shift every single note! Looks like this:

Notes on grid.PNG

So as long as you work inside that (time shifted) clip you don't have to worry about getting exact transients and with a little effort you can select multiple clips on a track and shift them in one go.

Unfortunately that doesn't work for launcher clilps. For this I found this quite useful:

Shift launcher clips.PNG

(also works for arranger clips in clip content editing mode but that's the same as moving the clip forward in the arranger)

[markussomething]

so how many ms of shift would this be?
Would be great to have a shift option based on ms for the clips then and not the whole track, or to have the timeline changeable to seconds instead of bars.

errr.... whoops *g

well... in that case.. fl studio does some things right. it shows several units in one line. and if people are interested in relative values for a certain unit more than absolute values, that is ok?

1.1.4.95 -1ms

fl studio has a few spaces inbetween afaik. but i can read it without that.

that timeline/ruler you mentioned would be nice too. then again, especially a mixed units ruler (beats absolute, ms relative):

Code: Select all

 in normal beats--|
                  V
-3 ms -2ms -1ms 1.2 +1ms +2ms

now they start uploading pictures again and i have only ascii art.

[Cyoon]

double post

[Cyoon]

From the manual:

These four units are shown together with period spacers in this way: BARs.BEATs.TICKs.%
For example, with a default time signature setting of 4/4, 1.3.4.50 would represent an event happening in the first bar, on the third beat, within the fourth sixteenth note, exactly halfway to the next sixteenth note.

so the last values are TICKs, maybe i'm too dumb to figure this out but a TICK would be related to the bpm wouldn't it? So if i offset a clip -5 ticks, this would be a different value in ms at 100bpm compared to 5 ticks at 180 bpm, or am i wrong?

[UncleMarty]

Useful little chart for those interested

http://www.sengpielaudio.com/calculator ... potime.htm

[dom@bitwig]

Being able to change those position parameters not only based on the bars and beats but also based on msec or samples would be nice.
Requires a bit of thinking how to do it best, as how many msec a beat actually is defined by the project tempo, which is automatable etc. but that might be something for the future.

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

[Cyoon]

Awesome!

[takaii]

Being able to change those position parameters not only based on the bars and beats but also based on msec or samples would be nice.
Requires a bit of thinking how to do it best, as how many msec a beat actually is defined by the project tempo, which is automatable etc. but that might be something for the future.

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

Sounds good.
Cause the timeshifting have one problem. And that is when you automation on bpm, if you do something like put it ofshift then automate the bpm then you would have to ofshift again cause the value of ms for the intervall ofshift will respond to diffrent value of MS

[dom@bitwig]

That's what i was trying to say with "Requires a bit of thinking how to do it best, as how many msec a beat actually is defined by the project tempo, which is automatable etc. but that might be something for the future."

Welcome to the wonderful strange concept of "time", fun, isn't it?

[Cyoon]

hehe, yea time is funny:D and so relative..

[duncaaan]

Splendid.

Speaking of time... Any chance of compensation for the delay of 1.2?

Only kidding - can't wait!!

[owensands]

I agree with Dom. Its not needed. You have plenty of control using SHIFT and drag coupled with the snap modes to place anything where-ever the heck you want it.Be it audio or midi. Also controlling is easy with delay tricks. There is a free delay plugin from voxengo that will do the trick perfectly.