a definition of chiptune

tl;dr version: chiptune is the combination of programming and music; it is also neither a medium nor an instrument, but a concretely defined, self-representative container
full version: http://pastebin.com/vPBCiGtW

***

there are many strata of what qualifies as sufficiently authentic chiptune, even within those who practice them to the full extent; for the novice it could be whether vrc6 could play on a nes, while others would be more concerned with the cpu architecture itself. but there has to be a minimum representational threshold that separates the "fakebit" and actually allows us to identify such category of music before any argument could start, and while this split is often exacerbated by youtube uploads that claim to be genuine yet turn out to be produced otherwise, those videos *do not* define the category of music necessarily different from genuine chiptune to be called "fakebit", that do not strictly pass the threshold

this threshold is not technical, but representational; in the past when people made chiptune, there was not only a music composer but also a music programmer, who had to produce the code that converts musical data into machine-readable formats, handles notes and effects from a binary stream, processes them at every cycle update, and processes sound effects in real time, while having to account for the memory size, the cpu workload, the complexity of of music data, and so on

then a music composer would have to first take care of the hardware limitations, which would then have been considered "fundamental"; the behaviour of the 2a03 or the sid 6581 must be completely known by both the programmer and the composer. after that, the composer also has to realize the expressive power of the sound driver, which directly contributes to the stylistic complexity of the music; this allows us to reason in terms of the disassembled code why for example mahjong, having a sound engine which fits within 200 bytes, does not produce sounds as complex as the sound driver found in silver surfer (this is where some people suspect that certain authentic, expressive chiptune tracks are "not real 8-bit", and i have received comments like that on my channel several times. ignore these people)

similarly, one can never replicate *anything* with 2a03 channels except dpcm and made in famitracker using the megaman 3 sound driver, unless one is dedicated to convert an arbitrary stream of register states into a blank instrument and many volume / fine pitch commands; here the conversion is technically possible, but not representationally feasible, plus the resulting data is no longer generated from the environment originally used to produce megaman 3 music. in this case i do not consider this as "authentic" chiptune because even though the music is perfectly capable of being played on a real nes, the final representation *does not depend on the sound driver's features that give form* to music produced for such sound driver; VST plug-ins convert MIDI events into audio streams or manipulate these streams, which are not fundamental to the representation of chiptune music data, so they do not constitute "authentic" chiptune either

if a tracker runs natively on a video game console or a computer comprising a suitable sound chip, then the music produced with it is trivially authentic; "suitable" means that atomic units of the tracker's music data communicate with the sound chip directly, e.g. ntrq will access the 2a03 registers directly, a sample-based tracker running on an amiga will access the paula channels to generate sound, as opposed to a sound card that only produces a sound signal from a DAC and an audio sample buffer. if instead a tracker runs on another system, it must guarantee that a corresponding sound driver is able to handle the music data produced by the tracker on a real system comprising such sound chip; as in, both famitracker and addmusick have working asm source codes for the respective sound engines used for nsf or spc, and their compilers yield legal music data whose pointers and values would be ensured to refer to valid objects assuming the sound engine as well as the conversion process are both free of glitches

one could go as far as rejecting all music in the vgm format, since they are just register write streams that comprise no hierarchical representation of the underlying music; the sound driver's implementation, central to the definition of chiptune, is completely removed in the rendering of a vgm file. however, since there has never been an emulating format for the sega genesis, people have generally accepted it as a technical threshold which qualifies chiptune as authentic, although the specification itself has evolved over time to act on more than one chip; one way to substantiate "authenticity" is to play the vgm on a native vgm player, so that technically the vgm can be played, but doing so will not recover the sound driver's details that generate the vgm files

on the other hand, we have accepted famitracker modules and nsf files as authentic by and in themselves, but this is only possible if the nsf players are verified to accurately emulate the 2a03, and famitracker's own sound processing code yields an emulated sound output sufficiently close to that provided by the nsf driver's workings. the job of verifying the accuracy of nsf players and non-native environments lies within their respective developers; in particular, emulators are sometimes capable of playing any representable music even though the respective players may forbid certain features per specification (e.g. bankswitching, nsf interrupts)

so what i would call "authentic chiptune" must satisfy these criteria:
- there must be a sound driver that handles well-formed, natively generated music data on a system and communicates with the system's constituent sound chip / sound card;
- the sound chip / sound card must be able to generate continuous sound signals and handle its own internal state variables autonomously;
- one must ensure that a representation of the music data and the sound driver, native to the target platform, can be generated from the source format if such format is not native;
- if it exists as another format not native to the sound chip, it must generate the same music output as the converted format without losing or augmenting information.

these criteria would pass easily for environments with native bytecode compilers, like famitracker or ppmck; in particular this definition does not care whether there are multiple sound chips (in practice, 2a03 + vrc6 would not be much different from 2a03 + 2a03, or 5× ym-3-8910) or whether there is post-processing. it also sets a loose limit on the sound chip; the sound chip is only required to behave autonomously, so that after its period / frequency register is written, it can generate tones at the frequency as designated in its hardware specification, while no limit on the hardware's resolution or expressive power is imposed. the difference between a sound chip and a sound card is not important here, as long as they could behave autonomously; for instance, the psx has a sound chip, neither the game boy nor gba has a distinguishable sound processing chip, whereas earlier computers like pc-98 have fm chips like ym2608 or opl3 as a sound card

from one point of view, a chiptune is nothing more than an autonomous assembly code program with a constant storage of music data; given the sound chip's hardware characteristics and the opcode instructions that communicate with the sound chip, the chiptune deterministically generates the musical output. but chiptune must also consist of the tools that produce the music data in the designated formats, as well as hardware architectures designed to play the chiptune itself, to possibly allow processing of the musical output in a way that does not interfere with the inherent sound driver; these aspects together construe chiptune as an interface that efficiently transforms binary data into executable musical output

cont.