☰

antonsavov.net → antto

Articlesexch303fmt

Jump to Section

Exchangable TB-303-compatible format.

The main goal is to unite all TB-303 clones and emulations which are capable of reproducing the patterns the way they are on the original.

That plus:

  1. Easy to copy/paste patterns on internet Forums and IRC

  2. Easy for humans to read the format and edit as text (ideally it should be in 303 pattern notation)

  3. Easy for converting the format on the hardware clones

  4. Support multiple patterns (up to 4) like on the TB-303

  5. Store just the significant (to the 303) information

Due to the inconsistency of #1 and #2 with #3, the format can be divided into 2 sepparate formats:

  • Plain-Text, which will satisfy #1 and #2

  • Binary, which will satisfy #3

The software clones have the luxury of running on super fast computers, so parsing text is no problem. So to make things simpler:

  • When loading the Plain-Text format - the parsing function will output the pattern in the binary format.

  • When exporting to Plain-Text format - the exporting function will take the binary format as input.

From the point of view of the 303 clone
In all cases, the actual effort will be to implement 2 functions which will be specific to the clone:

  • a function for converting from the binary format to its own internal format

  • a function for converting from its own internal format to the binary format

The parser and exporter functions will not change.

Software clone

  • can support both the Plain-Text and the Binary format

Hardware clone

  • should support the Binary format only

Nothing fancy please

Almost all 303 clones have taken away some restriction or added features on top of the original.

  • Extended transpose range to the notes in the pattern

  • Notes beginning with slide

  • Accent on Rest

  • Exotic Note durations and/or Shuffle

  • Control over some of the Tone parameters (like automation)

  • who knows what else

These extra features are incompatible with the TB-303, and are beyond the scope of this format.
Each clone already has its own native format which can store all that exotic information, and it can freely change its own format whenever it wants without this breaking compatibility with other clones.

The TB-303 pattern (and sequencer) will never change.
That’s why this format here can safely be based on the original.
This will guarantee that any true TB-303 pattern can be loaded and reproduced on all clones which support this format.
The exotic features will be lost when exporting to this format, but that’s expected, since you couldn’t reproduce those on the original either.

Plain-Text

This format could be stored in files with .303 extension.
It should be in 303 pattern notation (like on the TB-303 pattern sheets, sepparate Time and Pitch information).

A pattern could be written like this:
TM: <time information>
PM: <pitch information>
An example pattern:
TM: GGGG GO-- GOOO --GO (16)
PM: c, d, a#, b(us), f#(a), C(ua), c(d)

This way, the pattern can be read easily by a human, and it can be programmed on a TB-303 'as-is'.
On the first line, there is "16" which means that the pattern length is 16 steps, and there is the time information for each step, where:

  • G stands for Gate (Note Begin)

  • O stands for Tie (Note Continue)

  • - stands for Rest

If the pattern is Triplet, that’s written with a T char:

TM: <time info> (12T)

On the second line, there’s the pitch information. Each entry begins with the Key followed by the attributes (those which are set) d, u, a, and s.

Note
 The pitch information is case-sensitive, all keys and attributes should be lower-case, upper-case C is for the high-C on the TB-303 keyboard.

Making it simple for the user Copy/Paste on forums and even IRC

A special char can be used to act as newline, for example '\'.

Then a pattern can be crushed into 1 line and pasted on IRC:
TM: GGGG GO-- GOOO --GO (16) \ PM: c, d, a#, b(us), f#(a), C(ua), c(d)

Making it even simpler for the user to Edit the pattern manually

The Parser can be made very tolerant.
For example, a note is really delimited by the white-space, and the brackets around the attributes are not required, same goes for the comma.
This can be achieved by making the Parser strip the brackets away, and convert commas into white-spaces, and then remove double-occurances of white-spaces.

Thus, when the parser sees: c#(duas), f(d)
it will turn it into: c#duas fd

This means that even the user can write the pattern in such "minimal" way, and the parser will still parse it properly.

Another example with the time information - G and O can be converted to lower-case, thus it will be possible to write them in any case.
The pattern length is not required by the parser, so it can be ommited, the parser will count the number of time values to determine the pattern length.
The spaces between the time values aren’t required.
So when the parser sees: GGGG GO-- GOOO --GO (16T)
it will turn it into: gggggo—​gooo—​goT and because there is T indicating that the pattern is Triplet, the pattern length will be restricted to 15 steps.

Binary

The realization of the binary format is slightly more tricky.
Again, computers have advantages and can tolerate all kinds of complicated formats.
The most common hardware 303 clones appear to have MIDI in all cases, the TB-303 cpu modifications tend to add MIDI too - one idea is to use MIDI Sysex.

MIDI Sysex?

The files will have .syx extension and could be loaded into one of the many MIDI apps which deal with Sysex.
It could also be transmited between clones which have MIDI.
The sysex message would use a manufacturer ID followed by a few special values which will serve as a magic code, and should never change.
The raw binary data of the pattern(s) can be encoded simply by spliting each byte into two, using the low 4bits of each byte.
The actual raw binary data of the pattern can fit into 16 bytes, just like it does on the TB-303.

Should there be information about the pattern location?

No.
Automated pattern dumps are beyond the scope of this format.
Each clone should have another mechanism for that purpose.

Multiple Patterns?

Yes.
Since the TB-303 can chain up to 4 patterns and edit them as one whole, this format should make possible to fit up to 4 patterns into the same binary file.

The User Interface?

An idea of how the interface could work:

  1. The user wants to import a pattern from his computer to his hardware clone.

  2. There’s a MIDI connection from his computer to the clone.

  3. The user prepares his clone to start listening for a 303 pattern over sysex.

  4. The user sends the pattern from his computer, the clone recieves.

  5. The clone converts the data to it’s native format. Now it’s up to the clone what to do:

    1. put the pattern(s) into its pattern buffer and play them

    2. ask the user where to save the patterns

    3. discard?

Sending pattern(s) from one clone to another via sysex can be done in a similar way:

  1. The user connects a MIDI cable from the clone which should send (A) to the one which should receive (B).

  2. The user Selects which pattern(s) he wants to send on (A) and prepares (B) to receive, just like shown above.

  3. Clone (A) starts sending the data, (B) starts receiving.

  4. …​

Last updated: 2013-07-18