Jump to content
apt

How to Apply an Absolute Time Offset to MIDI Tracks (by ms) ?

Recommended Posts

Posted (edited)

In many sample libraries it requires a "negative delay" to the midi track (e.g. -100ms).

But it seems that the "time +" in Cakewalk's midi tracks is by "midi time" (ticks), not by ms.

image.png.dc122d0f2cb312eb5cdd68919b29d306.png

I know it's okay to manually convert ms to ticks according to the tempo, but if I have tempo changes in the project, the absolute time offset would not be consistent.

So, is there a way to delay midi tracks by absolute time in Cakewalk?

Edited by apt

Share this post


Link to post
Share on other sites

Wouldn't the time offset still be wrong after a tempo change whether you specified it in ticks or milliseconds?

Assuming, of course, that the "negative delay" required by your sample library is dependent on tempo in the first place. Usually, when an offset is required, it's to compensate for a baked-in slow attack time in the samples, which would remain fairly consistent across a wide range of tempos. Just thinking out loud, as I've never had an issue with MIDI offsets. I usually set the time offset by ear anyway.

Share this post


Link to post
Share on other sites
1 hour ago, bitflipper said:

Wouldn't the time offset still be wrong after a tempo change whether you specified it in ticks or milliseconds?

Assuming, of course, that the "negative delay" required by your sample library is dependent on tempo in the first place. Usually, when an offset is required, it's to compensate for a baked-in slow attack time in the samples, which would remain fairly consistent across a wide range of tempos. Just thinking out loud, as I've never had an issue with MIDI offsets. I usually set the time offset by ear anyway.

Thanks for the reply!

Actually I firstly found this problem when I did tempo changes like this, which is common as a transition between two sections:

image.png.1310e2499f569456ed7ecb0efc302da7.png

If there's a midi track with time offset by ticks, and you do this, the notes that begin at the 8->120 jump would come out much earlier than expected.

 

Share this post


Link to post
Share on other sites

OK, got it. I'm thinking in terms of how I use tempo changes, which are never that severe. It's not just MIDI-driven synths that are affected by fast tempo changes; tempo-synced delays also have problems. So I generally avoid them. On the rare occasions that I do need a drastic tempo shift, I'll build the ritard into the performance and leave the tempo alone. Again, it's just my own way of doing things - all my MIDI parts are played, rarely hand-planted into the PRV.

But regardless, the answer is still no, you cannot specify offsets in fixed time intervals. Seems that would introduce CPU overhead as the DAW continuously recalculated the number of ticks required to maintain a consistent absolute time. Tempo resolution can be as low as 3 ticks, so you could be recalculating offsets 320 times a second -assuming you haven't changed the number of ticks per second.

I'd be looking at why MIDI timing offsets were needed to compensate for a sample library in the first place, and if there might be another way to approach it. Many synths let you change the starting point for sample playback, for example.

Share this post


Link to post
Share on other sites
14 minutes ago, bitflipper said:

OK, got it. I'm thinking in terms of how I use tempo changes, which are never that severe. It's not just MIDI-driven synths that are affected by fast tempo changes; tempo-synced delays also have problems. So I generally avoid them. On the rare occasions that I do need a drastic tempo shift, I'll build the ritard into the performance and leave the tempo alone. Again, it's just my own way of doing things - all my MIDI parts are played, rarely hand-planted into the PRV.

But regardless, the answer is still no, you cannot specify offsets in fixed time intervals. Seems that would introduce CPU overhead as the DAW continuously recalculated the number of ticks required to maintain a consistent absolute time. Tempo resolution can be as low as 3 ticks, so you could be recalculating offsets 320 times a second -assuming you haven't changed the number of ticks per second.

I'd be looking at why MIDI timing offsets were needed to compensate for a sample library in the first place, and if there might be another way to approach it. Many synths let you change the starting point for sample playback, for example.

 It's true that this feature is somewhat not easy to implement... But what made me post this thread was that Cubase and many other DAWs can do this. Maybe I should make a feature request...

As for why it is needed... For example, using Strings Staccato, there is an "attack" before the "rhythmic start point" of a note. If you simply set the sample start to that rhythmic start point, it would be unnatual. The only way to both keep the piano roll tidy and hear the notes in rhythm, is to apply a negative offset to the midi track.

Anyway, thank you!

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...