KSEQ to ESEQ file conversion

[animaux]

Wow, Track #9 from the demo is converted 1:1 from KSEQ compared to the MIDI file.

Haha, stupid me, I was comparing two different exports from my converter

[animaux]

Here are some kseqs in song mode. Each kseq file is one bar of C notes quantized. I have quantized full and half note to 1/2, the quarter to 1/4 and eitgth notes to 1/8. If I should repeat this and quantize all to 1/8, let me know. About that kseq with a full minute: what notes should this be? or should the vary full notes, half notes, quarter notes per bar or something like this? I hope the access to dropbox works. I think they may have put an email registration in front of it.

Brilliant, many thanks! Dropbox works fine, I can skip registration. I’ll have a look at it in a minute!

Could you do the 1 or more minute KSEQ as multitrack with the different note lengths in different tracks together in a single sequence? One version without quantization and another one with ⅛ maybe (as the common denominator).

Another thing: could you please save them as »Sequencer All« .Kxx-Files? Currently my converter is not able to open the .Mxx-files directly yet, so I have to add the SY1_SEQALL-part of another file, that might affect the following COM-KSEQSY1_SEQ-part (essentially the .Mxx-File).

[bnz99]

Ah ok, I assumed that I should save the kseq directly. I'll save them again and then make the multitrack one. I'm glad I can help.

[animaux]

Many thanks, I think I can actually modify the converter to accept both with a quick and dirty hack

[bnz99]

The dropbox link is updated with the resaved files. I'm still fighting against and illegal input error the copy measure function. It's been 30 years since I have used that last

[bnz99]

Updated again:
UQ.K05 is unquantized with track 1 full notes, track 2 half notes, track 3 quarter notes and track 4 eigth notes repeated for 99 bars (I hope the minute wasn't important).
Q.K06 is the quantized version to 1/8 on each track repeated for 99 bars.

[animaux]

The dropbox link is updated with the resaved files. I'm still fighting against and illegal input error the copy measure function. It's been 30 years since I have used that last

Haha, nice that you still got it working! Many thanks again for the test files, I will dig into them and report!

The idea behind having a minute or more is to check if there is something going wrong with timing after some time. But that might need more factors to happen. It’s good to check with very basic files.

[bnz99]

I have tried to convert a file. While the individual parts don't sound bad, the starting points of the individual track sequences and their alignments seem to be all over the place. Maybe it makes sense to create another test file where there is like a full note on bar 1 on track 1, then a full note on bar 2 of track 2, then a full note on bar 3 on track 3, etc. or maybe with even bigger spacings. Just from listening (and not having looked at the format), I have the impression that there may be some metadata that compresses empty measures. But you let me know what you want to have.

[animaux]

… the starting points of the individual track sequences and their alignments seem to be all over the place. …

That’s what I find as well . I think I just found a reason for why this happens. Looks like my sequencing of events doesn’t take multiple sequential deltas into account. That might just be the worst problem at the moment. (edit: n’ah, that’s not the problem, I already thought about that)

[animaux]

The multitrack is really helpful, great! It seems to prove my theory that quantisation has some effect on individual track tempo resolution, or at least that different tracks have different temporal resolution, or my calculation of delta times is borked in some other way.

The result actually sounds like some nice John Cage piece

Still confused, but here are my findings so far:

Start times quantised version

Track 01. full —> off by a factor of 2 (only each second beat a full note is played)
Track 02. half —> off by a factor of 1.666
Track 03. 4th —> on time
Track 04. 8th —> on time

Start times non-quantised version

Track 01. full —> off by a factor of 1.666
Track 02. half —> off by a factor of 1.666
Track 03. 4th —> on time
Track 04. 8th —> on time

Half and full notes are encoded as »long notes« in KSEQ, 4th and 8th notes are »short notes« and seem to be fine. If it wasn’t for the different factors in long notes this would be easy to solve. But I will figure this out.

[animaux]

Ahhhhh! Looks like it all the effects can be attributed to my still slightly wring interpretation of delta encoding in KSEQ. If anyone is interested in the technical details:

Track 01, full notes (96*4=384 ticks)

Code: Select all

10100011 00000000
      11 00000000 —> 768
      11  0000000 —> 384

Track 02, half notes (96*2=192 ticks)

Code: Select all

10100001 01000000
       1 01000000 —> 320
       1  1000000 —> 192

So basically I get too large values because I interpret the first bit of the second byte as a digit of the tick value, which it is apparently not. This generates the factors of 2 and 1.666.

Now I just have to check if deltas can have three or four bytes as well. Also check if this pattern is true for long notes as well.

[animaux]

OK, the converter now seems to handle the timing right, please give it a try:

https://animaux.de/kseq/

------------------------------------------------

The revised KSEQ encoding is thus:

KSEQ track format

Track start and number (2 bytes)

Code: Select all

11110000 nnnnnnnn

n = track number (0 = track 01, etc.)

Track end (1 byte)

Code: Select all

11110010

KSEQ note format

Long notes (4 bytes)

Code: Select all

1101llll 0lllllll 0nnnnnnn 0vvvvvvv

Short notes (3 bytes)

Code: Select all

1101llll 0nnnnnnn 0vvvvvvv

l = 4 or 11 bits for note length value in ticks (apparently 24 ticks per ¼ note)
n = 7 bit note value
v = 7 bit velocity value

KSEQ delta format

Long Delta (2 Bytes, >= 32 ticks)

Code: Select all

101lllll 0lllllll

Short Delta (1 Byte, 0–31 ticks)

Code: Select all

100lllll

l = 5 or 14 bits for delta length value in ticks (apparently 96 ticks per ¼ note)

[animaux]

This would mean that max. note length 2047 ticks (in 24 ticks per quarter note), which would be ~21 bars.

To test this assumption, I have one final request for a test file at the moment: A Sequence with a single note sustained for longer than at least 22 bars

[bnz99]

I'm on it.

[bnz99]

There is a LONG.K08 in the dropbox folder. I think you are onto something. I have recorded the long note for 26 bars, but in the playback it stops somewhere directly after bar 21.