# README
go-challenge-1
This is my implementation for the March 2015 golang challenge.
Build
This project uses a Makefile to build itself. If you have cloned the repository, and are building it locally, you can build this library by issuing the following command:
$ make
This will run go fmt, vet, lint, errcheck, and test the library, and finally resulting in building the package.
Usage
This library is intended to be imported and used within your go project, so to get started, just import the library!
package main
import (
drum "github.com/kellydunn/go-challenge-1"
"fmt"
)
func main() {
pattern, err := drum.DecodeFile(path)
if err != nil {
fmt.Printf("Error opening pattern: %v\n", err)
}
fmt.Printf("Loaded pattern: %s\n", pattern)
}
File Protocol
Part of the challenge is the reverse engineer the .splice file protocol. In this section I talk about the comoponents of the file protocol that I reverse engineered, and how they work together to create the .splice file format.
Header
The first section of any .splice file is the header sectoin. It appears to contain a File Type and a File Body Size.
"SPLICE" File Type
The Splice file type appears to be fairly simple: a 6-byte string with a static value of "SPLICE". This identifies the file as a .splice file.
Splice File Body Size
The Splice File Body Size appears to be an unsigned 64-bit integer that describes the length of the Body of the .splice file in bytes. It should be noted that pattern_5.splice is the only example file that has extra, erroneous data encoded in it that occurs after the aforementioned Splice File Body Size. Since the tests that came with the challenge seem to require this file to be successfully decoded as a Pattern, I have decided to discard any data in the file that occurs after the Splice File Body Size.
Pattern
The First Part of the body seems to encode the Pattern Version followed by the Pattern Tempo.
Pattern Version String
The Pattern Version String seems to be a 32-bytes in Length. The unused bytes also seem to be discarded in order display the version string correctly.
Pattern Tempo
The Pattern Tempo sems to be encoded next in the file as a floating 32-bit number.
Tracks
The next substantial section of the document appears to be all of the Tracks in sequence.
Track Id
The Track Id appears to be a unsigned 8-bit integer.
Track Name
The Track Name is comprised of two parts encoded in the file. First, appears to be an unsigned 32-bit integer which describes the size of the track name in bytes. This value is the number of bytes in which to read off of the file in order to receive the name of the track.
Track Step Sequence
The final component of each Track looks to be a series of 16 bytes, each of which describes whether or not the corresponding track should be driggered for a given 16th note in the step sequencer.
Happy Hacking!