Note's Length

[liquidsound]

I noticed that the length of any note is not even to the measure but a .0001 shorter. For exsample a 1/16 in the list editor is 0.0.0299, 1/8 is 0.0.0599 etc.
It is not the List Editor giving the wrong value because when the Midi data is exported I get the same values in the other program's imported midi file.

This is strange....

[MuTools]

It's intended so to make sure a note ends before an adjacent note on the same key starts. I.e. note on/off management.

[pljones]

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.)

[liquidsound]

It's intended so to make sure a note ends before an adjacent note on the same key starts. I.e. note on/off management.

I can not grasp the technical reason though because when I quantize them (+0001) to the right length there is no problem playing them.

Also in all other daws the notes are always at the full length (unless they display the full number but internally the note is shorter as in MuLab.... well maybe not because when imported they show at 0.0.0001 shorter so other daws display the true length).

So how do other Daws manage 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.)

Check other Daws. No one has this behavior unless it's invisible to the user while MuLab it's transparent (?), WYSIWYG, Right? Wrong?

I find the full length system (Other Daws) to be less confusing and theoretically and practically correct.
Can MuLab do that trick?

[liquidsound]

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.)

Then why is it that after quantize them to full length they play normally?

[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.)

If a note starts on 1.1.0000 and has a length of 300 ticks, its note off is sent on 1.1.0300.

[MuTools]

It's intended so to make sure a note ends before an adjacent note on the same key starts. I.e. note on/off management.

I can not grasp the technical reason though because when I quantize them (+0001) to the right length there is no problem playing them.

It also depends on the target synth's note on/off management.

So when a note off stops before the note on, possible probs (ie the note off cutting a new note on which happen to start at that time) are avoided.

[liquidsound]

It's intended so to make sure a note ends before an adjacent note on the same key starts. I.e. note on/off management.

I can not grasp the technical reason though because when I quantize them (+0001) to the right length there is no problem playing them.

It also depends on the target synth's note on/off management.

So when a note off stops before the note on, possible probs (ie the note off cutting a new note on which happen to start at that time) are avoided.

Still... how other programs manage this issue?

[MuTools]

Currently it's like this:

1.1.0000 note C4 with length 300 ticks
1.1.0300 note C4 with length 300 ticks

Playing this to a synth may cause a problem that the note off of the first note cuts the note on of the second note. That's why MU.LAB defaults to make the length a tick shorter when you draw them in the sequence editor. The fact that it's a tick shorter won't make a musical difference.

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. I'm confident there is no musical problem. If you think it is, let me know.

[liquidsound]

No a problem really but an after thought about quantize the length of the notes in MuLab since it gives the round up to the even length.
That means: Use it at our own risk....

[MuTools]

Point understood, thanks.

[pljones]

If a note starts on 1.1.0000 and has a length of 300 ticks, its note off is sent on 1.1.0300.

That implies the following:

[MIDI source] 1.1.0000 Note On
[MIDI dest] waits until 1.1.0001 before starting note
[MIDI source] 1.1.0300 Note Off (000 to 300 is THREE HUNDRED AND ONE ticks. Like 0 to 9 is ten numbers, not nine.)
[MIDI dest] DOES NOT wait until 1.1.0300 before stopping note (otherwise the note length is wrong at the dest)

That doesn't seem logical or self-consistent.

[MuTools]

If a note starts on 1.1.0000 and has a length of 300 ticks, its note off is sent on 1.1.0300.

That implies the following:

[MIDI source] 1.1.0000 Note On
[MIDI dest] waits until 1.1.0001 before starting note

Huh Why?
It's all not that complex.

[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'.

[TheGuysanIdiot]

Hi All,

This is my understanding of ticks.

A tick is a length of time. It has a duration (start and finish position).

In this case most DAWs will use 300 ticks.

So from 1.1.0000 to 1.1.0300 = 300 ticks (gaps)

0 to 1 = tick 1 (this is a duration of time starting at 0 and ending just before 1 starts)

1 to 2 = tick 2

2 to 3 = tick 3

299 to 300 = tick 300



So Jo could write MU.LAB to use 300 ticks (gaps) and there would be no overlap in theory. But by using 299 duration gaps there will always be a one tick duration between notes to be on the safe side. Especially notes of the same note value following each other such as C3 following C3 on occasion it is possible that the second C3 note will not trigger.

298 to 299 = tick 299 (gaps/duration of time)

I think this is correct anyone disagree?

OZ