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.
Easy to copy/paste patterns on internet Forums and IRC
Easy for humans to read the format and edit as text (ideally it should be in 303 pattern notation)
Easy for converting the format on the hardware clones
Support multiple patterns (up to 4) like on the TB-303
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.
This format could be stored in files with
It should be in 303 pattern notation (like on the TB-303 pattern sheets, sepparate Time and Pitch information).
TM: <time information> PM: <pitch information>
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
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.
|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 '\'.
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:
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 -
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.
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.
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?
Automated pattern dumps are beyond the scope of this format.
Each clone should have another mechanism for that purpose.
- Multiple Patterns?
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?
The user wants to import a pattern from his computer to his hardware clone.
There’s a MIDI connection from his computer to the clone.
The user prepares his clone to start listening for a 303 pattern over sysex.
The user sends the pattern from his computer, the clone recieves.
The clone converts the data to it’s native format. Now it’s up to the clone what to do:
put the pattern(s) into its pattern buffer and play them
ask the user where to save the patterns
The user connects a MIDI cable from the clone which should send (A) to the one which should receive (B).
The user Selects which pattern(s) he wants to send on (A) and prepares (B) to receive, just like shown above.
Clone (A) starts sending the data, (B) starts receiving.
Last updated: 2013-07-18