Standard musical notation -- by which I necessarily mean the Western variety, since even Ucenescu had started rearranging Byzantine songs in this form as late as the nineteenth century -- is as expressive as it is imprecise. Or rather it's not the notation itself that is imprecise: words such as staccato or allegro have a clear meaning, but their interpretation, i.e. their translation into concrete musical form, is prone to subjectiveness. This is why not only, say, is Gould's interpretation of Bach clearly different from, say, Ishizaka's, but from this particularization of abstract form one may mainly draw inherently subjective assessments, such as the latter's sounding like a machine in comparison to the former's. And moreover, objective (or so-called "objective") assessments might end up not saying too much about a phenomenon which arises to a large degree from a subjective state.
Still, abstract form is rendered more precise by the premise of musical instrument. The pieces we know aren't simply composed, they are arranged for a particular means of bringing them to life, thusly providing context for the otherwise imprecise elements of the sheet. This is how you get to annotate said sheet with "lyrics" for example.
Speaking of musical instruments, the greatest achievement in musical tech of the last century -- and perhaps for a few more centuries to come -- is without doubt the synthesizer. In a certain sense, synths are very similar to computing machines: in the ideal, they are able to generate arbitrary information given arbitrary inputs, but the shape of concrete outputs is very much influenced by the concrete implementation of our "synth", which turns it from "the" synth into "a" synth. Can you see how this maps to my previous observation on musical instruments? Or, say, to my older one about "operating systems"?
The synth however is not merely an instrument; it is a meta-instrument capable of producing particular sound shapes as a consequence of particular configurations. Thus it would be somewhat of an error to attempt describing synth music using (solely) sheet notation. And from a brief look at our life in the age of information, we can deduct that synth music could be most appropriately described using... programs; and since the synth is a meta-instrument, then particular instruments could be modelled using built-in synth parameters as a starting point. At this point I should provide at least one example, all this leaving aside the particulars of standardization and (more importantly) lack thereof1.
The intersection between computers and music brings to my mind two examples: the Nintendo GameBoy and the Commodore 64, abbreviated as C64. Since I grew up with BASIC and since I have put more time into studying the latter example, I will focus exclusively on it. The C64 came with a so-called sound chip -- in fact a full-blown synthesizer -- known as Sound Interface Device (SID), which was implemented in multiple ways (6581 and variations, 8580), yet all implementations used a common programming interface consisting of a few configuration and command registers. Thus, "writing a song" on the C64 consists of writing a driver for this chip (the "music player"), along with some input data (the song). This is why all the various SID music formats popular around the nets encode the entire C64 program, usually written in MOS 6510 assembly, as part of the file. Thus any program for "playing SID files" is more or less equivalent to the implementation of a minimal C64, or at the very least a 6510 emulator. Moreover, you can have such a thing as a "SID player" on your computer entirely because someone went to great lengths to reverse engineer the synthesizer down to its finest details. This is why all SID players sound roughly the same, unlike MIDI, which sounds like... nothing, at least if we don't account for SoundFonts. By all means, this little chip looks like The Right Thing, which is why it lived so long outside (and sometimes even within) the musical mainstream.
One particular set of "SID players" and at the same time a set of musical composition softwares, is that of "music trackers". And from this set I shall randomly pull something called Goattracker, a tracker which still compiles on my modern Linux machine, despite its being almost two decades old.
Goattracker has a few basic primitives for programming songs. For sound shaping, it uses the SID control register, and furthermore it extends otherwise invalid values to provide programmable patterns such as loops or transposition within a structure called a "wavetable". The wavetable is an array of so-called "commands", each modelling base sound characteristics (e.g. the waveform) or otherwise implementing control instructions ("jump to index X"). And similarly, mapped on SID settings such as the filter cutoff frequency, Goattracker implements a filter table, a pulsetable (for pulsewidths for the pulse waveform) and a speed table (for programmable tempo and miscellaneous rhythm patterns). All these tables are indexed in a structure called an "instrument", which also contains the values to other SID registers, such as ADSR. And these values themselves can be programmed during song execution.
The fundamental time domain control structure of Goattracker is the pattern. The pattern is simply a programmable step sequencer, e.g. it plays sequences of notes using particular instrument configurations, it changes the current wavetable pointer in the song and so on and so forth. Patterns can be combined in something called an orderlist and multiple orderlists are placed together in a subtune -- the concatenation of subtunes is what makes up a song.
This is Goattracker in the nutshell. With this, along with the C64 programmer's manual as reference, the clever composer -- and "interpreter", but only in the sense that our composer pushes a "play" button somewhere -- may craft a full song from scratch within the limits of SID. It doesn't sound like much, but it has yielded some impressive results. It's certainly not enough for the so-called "professional" musician: of course there exist more flexible and more economically efficient means of making music on the market, or where have you. But those tools don't distill the essence of digital music-making nearly as well as SID and Goattracker (or music trackers in general) do, rather they provide an amalgam of means based upon "established tradition" in the field, or what have you.
Mind you, this isn't the case due to any minimalist/purist approach on SID or Goattracker's part. Together they form quite a complex music composition and processing stack and you can tell that not only by reading the implementation, but also by attempting to compose any non-trivial piece using said stack. I'm not a music professional, which is perhaps why, coupled with a long experience2 with music softwares, I believe that music trackers come closest to how a post-postmodern, or Re-reinassance system for musical notation would look like. Also with all the bells and whistles if you'd like, but certainly not without "music tracking".
This might not come as much of a revelation, but... it's worth noting in my opinion.
P.S.: Notice the "new" that I'm discussing.
-
This article started as a review of music software, notation standards and so on. Meanwhile I left those in my bag of private notes and decided to elaborate on the deeper point.
No, I simply don't feel like mentioning the endless "alternatives" out there, some quite close to what I'm describing here, others entirely wrong in a number of ways which I don't particularly think are worth explaining. We're living in the dark ages and all I can do is attempt to the best of my powers to separate the essential from the irrelevant and put it into words. And if I failed... then the comments box lies below. ↩
-
Yet somewhat superficial, but only in the sense that I didn't need to make commercial music, I simply looked for other qualities in my pieces than all the sophisticated sound processing they do nowadays.
But yes, I've made a bit of music in the last twenty years or so. Cine știe cunoaște. ↩
But does it work with an actual SID? ( oblig: http://www.loper-os.org/vintage/parallelsid/parasid.html )
I haven't tested it since I lack the hardware, but there is some code claiming to support HardSID.
Goattracker2 is "old school" code, it lacks the usual GNUisms (autoconf et al.) and its largest dependency is SDL, other than that the program itself is just portable C.
I'll do a write-up once I finish skimming it, I do have some thoughts to hack on the sequencing code for a bit.
I for one disagree on trackers being the future of musical notation, but lemme first lay out the problem as I see it because we need to be clear on what "tracker" means here.
Just as with the config file vs. computer program continuum, musical notation is about all the tradeoff between explicit and implicit.
The most explicit notation is the wave file (or mp3 or whatever). No room for interpretation. Advantages: every performance sounds exactly the same and exactly as intended (if you want that), can also represent non-Western music. Disadvantages: not compact, opaque (you can't easily identify and process events inside it), every performance sounds exactly the same (if you're a classical composer and don't want that).
Closer to the more implicit end of the scale is "Western" musical notation. Don't be fooled by all those symbols, they just basically disguise a tabular tracked representation of musical events, just like trackers. It explicitly specifies musical events (within a Western framework, e.g. 12 semitones etc etc) and maybe some interpretation guidelines here and there. The details of how we go from those events to actual sounds are totally implicit - what's a "violin", how exactly it should be operated for each note, whether the timing should be exact or just a guideline etc. Advantages: compact, processable, room for variation if you want that.
MIDI gets a bad rap because it's being used far outside of its intended purpose (live communication of musical events). It's not meant for musical storage, and AFAIK in the core standard instruments are purely abstract (there's no talk about violins, guitars etc). If you want to use it for that though, deep down it's almost exactly the same as Western notation: it encodes the events and nothing more. Yes, in General MIDI there is some talk about certain instrument numbers being e.g. violins etc., but since it's obvious that you can't capture the bajillion constructive, tuning and amping details of even just electric guitars with a single 1-128 number, that "information" might as well not be there. So the details of sound synthesis are totally implicit, and it's no wonder that it sounds like crap when you try to approach it with simple algorithms.
With trackers, it's a bit odd to focus on trackers for the SID since what's more well-known are the sample-based tracker formats from the Amiga-to-PC pipeline: MOD, S3M, XM, IT etc. But sure, there's trackers for the SID too, and for the Adlib (even I wrote one). Trackers also represent music in a tabular format, except they are a lot more explicit about the instrument-to-sound conversion. Either they provide the exact samples and an (implicit but well known) algorithm for how samples are to be played for each event, or they provide the exact settings for the OPL3/SID/etc. channels.
In a way, tracker formats combine the best of both worlds since they allow both for perfectly reproducible performance (if you play with the original samples and the algorithm stays the same), but also expose the events so you can change the samples, interpret them differently etc.
So are tracker formats the future? I don't think so, because on the events side they bring nothing new (they're tabular just like all the other examples), and on the conversion side, they're a bit too wedded to either a particular chip or simple algorithms for sample-based playback. The more you try to fancify the sample system the more you realize that you're really just compressing a wave file in an overcomplicated way. Once you forget about the conversion, well, the events you can just represent by abusing the MIDI standard some more.
The "future", I'm afraid, is just more of the same: wave files (and you're on your own if you want the events), or the proprietary formats they compose game music in (some of which are sort of tracker-like but not really).
Speaking of video game music, I've come across some examples that don't fit into the tracker system either because of randomness, etc. and would be better represented by a computer program. I've literally had to jury-rig a Javascript player so that I could have my own "copy" of music Totally Legally Obtained from a game. But more on that some other time.
> on the events side they bring nothing new
Why would they, though? For what it's worth, I'm more interested in their limitations, regardless of whether there's any novelty arising from there.
> they're a bit too wedded to either a particular chip
What's wrong with being wedded to a particular chip? Or, more precisely: do the supposed benefits of using a standard interface (e.g. MIDI) really outweigh the disadvantages? In my experience, actually composing some song is way more difficult than writing it down in a particular language (supposing you know said language).
But wait, let me try to explain a bit more where I'm coming from.
> It explicitly specifies musical events (within a Western framework, e.g. 12 semitones etc etc) and maybe some interpretation guidelines here and there
My whole point is that you can't simply wave away the interpretation guidelines, be they explicit or implicit. As we both know, musical pieces aren't merely laid down on paper as abstract, ethereal "compositions", they are arranged for particular instruments. Thusly each instrument gets its own staff and moreover you get stuff such as fingering patterns for string instruments, which are an essential part of the sheet even when they're missing -- for example, the guitarist will read the notes in a different way from the violinist and both of these are yet some steps removed from the tubaist. And I'm not even getting into percussion here. To reiterate: even "portable C" is written taking into account register sizes and type conventions, its portability is indeed quite limited and sometimes counterproductive enough to be worked around. The same goes for sheet music as far as I can tell.
There is a specialization element to sheet music which isn't at all obvious in "simple" songs. The great advantage of these synth-based trackers is that they expose this specialization element fully. In my opinion, their other advantage is that, unlike modern music software, they lack many of the means for needless sophistication -- although in theory they can be added, their absence is IMHO a feature.
> The "future", I'm afraid, is just more of the same
If you mean the future of commercial music, then I agree. Then again, there may not be much room for commercial music, say, twenty years from now. I guess we'll see.
> what's more well-known are the sample-based tracker formats
I got no problem with either, I think there's room for both synths and samplers in this world, they each have their place in the realm of musical expression.
> I've come across some examples that don't fit into the tracker system either because of randomness, etc. and would be better represented by a computer program
This brings me to my other point: 6510 assembly was actually the ultimate sequencer *and* tracking notation of its time. Depending on what folks want to achieve, they may wish to use this or a tracker of some variety or both. The good part is that the technology itself is neutral from this point of view, much unlike standard commercial studio equipment, which is "fit for purpose" rather than "made from cause".
Oh, and speaking of:
> But more on that some other time.
Why don't you start a blog or something? Your comment is ample enough that it could easily fit into a separate article. Just saying, it seems like you have things to say. :)
I did have a blog actually back in the days of Poli (R.I.P.), you were one of my (few) readers and commenters. Gave it up for a number of reasons, most prominently that I rarely, if ever, felt I had anything to say. Sadly, these days I only seem to be motivated to write in response to ideas emitted by others. On my own, it seems I will only fall back into a deathly stupor.
Still, from time to time I do think I should establish a site I fully control, for portfolios etc., and I suppose there might be room for a pseudo-blog there. I prefer to let my code do the talking, but sometimes it helps to write an article to flesh some ideas out ahead of time.
Oh, now I remember your old blog!
I find myself using my blog mainly as an "exercise journal" for ideas that have found themselves a relatively stable place in my mind after a certain period of time. Some of the ideas might turn out to be nonsense, I don't think that's a problem as long as I have the material readily available and I can sort out the relevant stuff. It's certainly worth the effort to allow oneself to look back, even if merely to snicker at one's past naivete.
Regarding public code sites: I think the blog (in general) is pretty flexible in terms of how it allows you to share code. You can only share links if you like, or add a readme, or even share the full code in literate programming style if you think it adequate. Even though most blogging softwares (call them Content Management Systems if you like) are pretty complicated beasts (I would know, I wrote a small one), they're extensible enough and at the same time self-contained enough so as to allow you to do in HTML just about anything you can think of. The blog is the best modern equivalent of ye olde chronicles, its function has merely been stolen and perverted by the platforms.
[...] that my recent adventures in computerized music are far from over, I've decided to step outside my comfy place in the world of old synths and do a [...]