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.

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.

> 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. :)

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".

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.

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.