Note's Length

[cytone]

Hi All,

This is my understanding of ticks...

Makes sense to me. As a test I loaded a VST with legato enabled. Adding some 16th notes after each other the synth plays back the notes separately as expected as the note lengths are 299 so there is a 1 tick gap between the end and start of the next note.
After using the note length quantize function it changes all the lengths to 300 so there are no gaps. The synth now plays back the notes in legato. I'm guessing that the quantize should not do this though.

[liquidsound]

Maybe I got Jo at the wrong moment.... but if what we are saying here it's true then all other Daws should have this issue from the very beginning which it's not. Could it be that even though they show 300 it is actually what Jo is doing with MuLab and the difference is that MuLab is showing the real thing while the other are rounding up for display only?

Jo must know this because his comment was

I don't know how other hosts work regarding this specific aspect and i'm not going to deep this out at this point in time, sorry, for good reasons.

Good reasons....

in XT or Reason or FL or etc. I never got an issue. So what is going on?
I like to get to know MuLab as deep as I can and I think it's good for me and for all of us.

[TheGuysanIdiot]

Hi All,

Creating a simple 16th note sequence in both Reaper and XT2 saving these out as MIDI.

Importing to MU.LAB the list editor shows lengths are 300.

These MIDI files play fine in MU.LAB.

Indeed creating the same sequence in MU.LAB and making the notes 300 also plays OK.

MU.LAB can handle 300 note lengths.

But Jo has decided to put a safety net in by making manually created notes 1 tick shorter 299.

Obviously the quantize length does not follow the 299 pattern but rather does 300. So the quantize lengths command does not have the 299 safety net idea.

So MU.LAB can handle 299 or 300 lengths. But using a 299 system it would remove any possible overlap with note ON/OFF messages with notes of same value (C3 followed by C3 etc).

There is nothing wrong with the way MU.LAB works, but the quantize lengths command does not follow the 299 standard idea. But Jo has already commented on that.

Musically 299 or 300 will probably sound the same.

So I guess to make MU.LAB correct with itself it needs to use 299 or 300 in all its commands.

OZ

[liquidsound]

Musically 299 or 300 will probably sound the same.

Agree. The important thing is the starting point and at 0001 shorter musically is not an issue.
But why only Jo had thought of it it's a puzzle...

Zen Proverb:
The tighter the net, the more holes you get

[TheGuysanIdiot]

Cubase SX2 has an option called "Length Adjustment".

You can put a value in ticks, such as 2. This will put a 2 tick gap between notes of same pitch, such as C3 followed by C3.

I have no idea how this is programmed only that it removes the problem of notes that do not trigger on same pitch etc.

Under normal circumstances a 300 value note will be fine. I have no idea what causes some notes not to trigger in some MIDI files.

Again this option is not used unless you have problems.

So 300 is fine 299 is just safer under all circumstances as far as I can tell.

Other DAWs may have this built in and set to 1 tick, who knows?

Anyway that is the extent of my experience with ticks and it is just stuff I have picked up along the way.

I am happy with what I know, but if anyone has other ideas I would like to hear them.

OZ

[pljones]

[MIDI source] 1.1.0300 Note Off (000 to 300 is THREE HUNDRED AND ONE ticks.

No! If you start something on second 10 and you end something on second 20 then there are 10 seconds in between. The end time is not 'inclusive'.

If an event starts after second zero of a minute and ends before second two of a minute, then it lasts up to 1 second. That second is called second 1 of the minute. A minute has sixty seconds. They are called 0 to 59. Each one of them lasts one second.

300 ticks are 300 ticks. The first tick is called tick 0. The last tick is called tick 299. But that's 300 ticks. A note with 300 ticks has a length of 300.

If you start saying that the length of a 300 tick note is 299, then you must also start saying that a minute has 59 seconds.

[MuTools]

If you start saying that the length of a 300 tick note is 299, then you must also start saying that a minute has 59 seconds.

Hey, i'm totally confused. Where did i say this?

[liquidsound]

Hmm, that doesn't quite follow.

To ensure your Note Off is before the next Note On, you want something like this:
Start time of 1.1.0000
End time of 1.1.0299
Start time of 1.1.0300
End time of 1.1.0599

I make the length of each note 300 ticks. 299 ticks would mean ending at 1.1.0298, etc. (This on the basis that an event "fills" the tick it falls on, rather than "falling between" ticks.)

I think the confusion is here:
On MuLab the Event Editor states Length= 0.0.0299 while you typed in your quote "End Time" which if that was true then you are right, the note would be 300.
But since MuLab says Length 299 (not End Time)[edit] then the end time IS 0.0.0298!

Right? Wrong?

[MuTools]

Jo must know this because his comment was

I don't know how other hosts work regarding this specific aspect and i'm not going to deep this out at this point in time, sorry, for good reasons.

Good reasons....

in XT or Reason or FL or etc. I never got an issue. So what is going on?
I like to get to know MuLab as deep as I can and I think it's good for me and for all of us.

FYI: The 'good reasons' are off topic.

On topic: There is nothing special regarding the times, lengths and their calculations. A note that starts on 1.1.0000 with length 0.0.0300 results in a note-on on 1.1.0000 and a note-off on 1.1.0300.

The only issue is that when both a note-on and note-off for the same key fall on the same moment, then it may be that the note-on is processed first, then the note-off, but this note-off immediately cuts the new note-on. To avoid this, they key editor defaults to -1 tick. But criticism is true that when you do Quantize Lengths, the issue may be back. Solution is to prioritize note-offs upon note-ons on the same moment. That's on the whishlist.

[MuTools]

Hmm, that doesn't quite follow.

To ensure your Note Off is before the next Note On, you want something like this:
Start time of 1.1.0000
End time of 1.1.0299
Start time of 1.1.0300
End time of 1.1.0599

I make the length of each note 300 ticks. 299 ticks would mean ending at 1.1.0298, etc. (This on the basis that an event "fills" the tick it falls on, rather than "falling between" ticks.)

I think the confusion is here:
On MuLab the Event Editor states Length= 0.0.0299 while you typed in your quote "End Time" which if that was true then you are right, the note would be 300.
But since MuLab says Length 299 (not End Time).

Right? Wrong?

Indeed, the Event List Editor displays the length of notes (cfr the column title), not the end time of notes.

[liquidsound]

Great! I'm off confusion now.

[pljones]

There is nothing special regarding the times, lengths and their calculations. A note that starts on 1.1.0000 with length 0.0.0300 results in a note-on on 1.1.0000 and a note-off on 1.1.0300.

0 1 2 3 4 5 6 7 8 9
10
That's 11 numbers.

So if an event starts at "0" and ends at "10", the event lasts through 11 ticks. I don't see how it can be 10 ticks.

So if an event starts at "1.1.0000" and has a length of 300 ticks, it should end at "1.1.0299". The Note Off event you send at 1.1.0299 you have to assume will be processed before a Note On event at 1.1.0300. But sending the Note Off at 1.1.0299 does not mean the note is only 299 ticks long - it's still 300 ticks long. The Note On is processed once tick 1.1.0000 starts and the Note Off is processed before tick 1.1.0299 ends. The duration of the note encompasses ticks 1.1.0000 through to and inclusive of 1.1.0299 and is thus 300 ticks.

(I better go check the MIDI Spec, but I'm pretty sure that's right.)

[cytone]

There is nothing special regarding the times, lengths and their calculations. A note that starts on 1.1.0000 with length 0.0.0300 results in a note-on on 1.1.0000 and a note-off on 1.1.0300.

0 1 2 3 4 5 6 7 8 9
10
That's 11 numbers.

In a C++ array it would be 11 locations but for time duration it is 10.

0-1 1
1-2 2
2-3 3
3-4 4

etc

[Branis]

So if an event starts at "0" and ends at "10", the event lasts through 11 ticks. I don't see how it can be 10 ticks.

It's actually 10 ticks as Jo said. I even made a small graphic to demonstrate it


if an event starts at tick 0 (at the green line) and ends at tick 10 (at the next green line) it lasts 10 ticks (10 black blocks).

[liquidsound]

If ZERO is considered a Tick then it takes a theoretical space in time and so that Tick has a beginning and an end at the beginning of ONE.
So if we count from the beginning of ZERO then we must stop at the beginning of TEN without considering TEN as a tick because its space in time has not be used even though we are at TEN, but only at its beginning as in ZERO.

So from ZERO to TEN we have 10 Ticks.

BRANIS's Bars are a good example indeed.

But I see what Pljones is saying... but the trick is Length and/or End Time