Editing drums_init.syx?

[moogah]

Sorry if this has been answered before, I'm assuming there is an application somewhere I can use to generate the .syx file type and that there is also some information somewhere on what format the SEQ wants..  I just can't find it at the moment..  Perhaps there are some PERL scripts that will help ;D?

Ok, I found the sysex page in MidiOx now, that answered alot of my questions ;D.  Now what I need to find is a description of the sysex formatting. 

[moogah]

Just about ready to get some sleep and continue tommorow.

A little bit of work in Excel and I've digested the file and posted a page to the Wiki containg a table describing the data as I understand it.  I assumed that the 320 bytes of data could be broken into 16 byte chunks and by doing this also found that there appears to be at least 5 sections to the dump, the first three containing 4 16 byte lines.

I'll post more details tommorow, until then check the wiki page

http://www.midibox.org/dokuwiki/doku.php?id=drummodesysex

[stryd_one]

You might want to link to that from another page (say the MBSeq one?) otherwise it will just float there....

[moogah]

Gotta make sure it's correct before I make it more visible ;)

[stryd_one]

Heheheh be confident ... At worst, it will be removed ;)

[moogah]

Good point :)

Now, chances are pretty good I'll have to take a nap once I get home from work today and therefore I won't get much done (still Fn sick..).  But here is what I'm thinking now:

There are definatly some recognizable patterns in the dump data, look at colums 9-12 in the first three sets.  Those alone are enough to re-inforce my assumption that the data is at least partially comprised of 16 byte rows.  However, I've not yet figured out where certian data is represented.  Since this is an unkown I'll be starting by figuring out what information the 320 bytes must represent. 

We know that a pattern contains information about 4 tracks, each with 3 layers and each layer with 16 positions that hold a value.  We know that the largest value a position needs to hold will be 127, which requires 7 bits.  We also know that a position being muted only needs a single bit.

We know that other track information needs to be represented as well.  The BPM divider, the play mode and direction, the event type all need to be represented as well.

We can assume that TK has been, as always, efficient with his code and little to no space will be wasted.

Next, what kind of specific information can we gather about this particular string?

We know that each layer will have it's own mute value and it will initialzed to off (0?)

We know that the information is used differently in drum mode and is probably more compact.  Perhaps someone has a .syx of a blank pattern they could send me?  I still can't upload to a PIC..

SO, with these assumptions what can we see?

Perhaps it's just a coincidence but the first 12 rows of data look likely to hold the information about the 12 tracks.  We can see that there are 3 sets of similar rows, leading to the conclusion that each set of 4 rows represents layers A, B and C for each of the 4 tracks.  We can see that within each "Layer" there are only a few differences between rows.  The first and most interesting difference is the 9th column.  This is the only unique column amoung the 12 rows and it is interesting to note that all the values between 24 and 2F are represented here.  The only other inconsistancy are the first 4 columns of the first row which contain "3E" instead of "3F".  Only this first "layer" has this feature.

We can see that each row of each layer starts with 8 identical values.  This is good, perhaps what we are looking for.  These 8 values are followed by rows 9-12 with their interesting relationship discussed.  It is interesting to note that column 12 has the same value for every row.  The last 4 colums for each "layer" are all the same value.

It is also interesting to note that there is an extra byte in the footer.  Although the "10" isn't part of the proper sysex command I don't believe it could be part of the data dump as we already have exactyly 320 bytes..

[TK.]

***SPOILER*** Here is the answer to this riddle: http://www.ucapps.de/midibox_seq/mbseq_sysex_implementation.txt ***SPOILER***

[moogah]

Awesome!  thanks TK ;D

I figured that the mute information could not be decoded by reading the hex and was just about to start converting those tables into binary and decimal  :)  I've got too much else to get done, but in the end I'll complete that wiki page by combining those documents and labeling the string with positions for drum mode and regular mode.

And, I assume that the offsets is a new addition to that documentation?  Otherwise I need to find the most recent SEQ .zip (2.4c, right?)

[TK.]

And, I assume that the offsets is a new addition to that documentation?

yes, before this addition they where only documented in SEQ_SYSEX_WriteP, SEQ_SYSEX_ReadP (seq_sysex.inc) and app_defines.inc

Best Regards, Thorsten.

[moogah]

Time for some more riddles  :)

I realize the data format is changing for V3, so this is just out of curiosity.  I've been tweedlin' with the sysex in order to create a default pattern for the 808 and I've found some interesting bits reguarding the mute and accent data.  I had assumed that only a single bit was needed to represent each step, and that does appear to be the case.  Except, there is a whole byte allocated to each 4 steps.. this is odd!  Odder still is that the high bits have a different value for each layer, although it does not seem to affect the pattern.  Even odder is that each set of low bits is inverted from what you would expect.  Follow this:

3E 3E 3E 3E 3F 3F 3F 3F 

Each location represents 4 steps with the hex "3E" for mutes or "3F" for accents.  The pattern is a simple 4-down kick drum, no accents.  Decoding the hex to binary we get:

3E = 0011 1110

3F = 0011 1111

Now, assuming each bit represents a step and a 1 represents an on step the pattern plays like this:

1000 1000 1000 1000

Which isn't what we see in the binary, even inverting the bits gets us:

0001

Still not what we want.  But at least we can see a relationship here, except that it's inverted on two levels.  So from this analysis we see that the sequencer reads each byte from low bit to high bit and the values are inverted.  Interesting. 

Another strange discovery is that changing any value in the mutes or accents causes my SEQ to drop tempo by ~50%.  Odd. 

[TK.]

In MBSEQ V2 a mute bit really means muted, and not gated. Therefore it's inverted.

In MBSEQ V3 gates are part of the trigger layers, and they are not inverted.

In MBSEQ V2 the upper 3 bits of the 7-bit word are ignored and are sometimes randomly set depending on the previous pattern data, and the 8th bit is always 0, otherwise it wouldn't be possible to send the data within a SysEx stream (data between F0 and F7 must be 7-bit values)

Another strange discovery is that changing any value in the mutes or accents causes my SEQ to drop tempo by ~50%.  Odd.

must be a programming issue in your changes...

Best Regards, Thorsten.

[moogah]

upper 3 bits of the 7-bit word

Ahh yes.  7 bits for MIDI.. I knew that... ::)

[moogah]

Alright, finally got around to doing some more testing tonight. 

The problem with the tempo dropping when drums_init.syx is edited happens with the unmodified source as well (taken right out of the .zip file).  At the moment I don't have any pointers to give on what may be causing it, but I'm looking at a possible mistake with the layout as that is the only X factor between this SEQ and any other one.

Perhaps someone can upload the file to their SEQ to test this?  All you have to do is change the first "3E" to "3F".. or "2A" or anything, I've found that any change to the data will produce the result. 

It's also possible that I've been careless while editing and somehow there is something akin to a checksum error that is causing the problem.  Work has been slow going lately as classes have started, but I will report back as I get more information.

[TK.]

How do you measure the tempo? With the MIDI Clock Slave of MIDI-Ox, or by listening to the beats?

Best Regards, Thorsten.

[moogah]

I'll get a specific measure of the tempo change next time I'm at the bench, but it is unmistakeable-watching the Tempo indicator and the GP LED's it is clear that the tempo drops from ~120 to ~60.  In fact it is quite possible that the tempo is 'saturating' to it's minimum value.  Heh.. not sure 'saturation' and 'minimum' are the proper match, but it's all I can think of at the moment :)