AY tracker routine
Hi.
Yesterday i played with some ay tracks and was surprised how big are tracker routines and music data (over 1.5KB for Pro Tracker routine and 4-6 KB for data).
So my questions are:
1) Is here a way to create more compact music ?
2) I know that intros and minigames uses its own custom players and data format. What you think is minimum of player features to create reasonable music ?
3) Is here an utility dedicated to create compact music ? Something which could be called "Minimal Tracker" or so ?
4) Do someone know how hungry are common tracker routines in sense of memory footprint and T-states taken ? Somehow i can't believe that all that demo coders were satisfied with routine which takes more than 15000 T every interrupt (i estimate that Pro Tracker takes about 20000 T).
Yesterday i played with some ay tracks and was surprised how big are tracker routines and music data (over 1.5KB for Pro Tracker routine and 4-6 KB for data).
So my questions are:
1) Is here a way to create more compact music ?
2) I know that intros and minigames uses its own custom players and data format. What you think is minimum of player features to create reasonable music ?
3) Is here an utility dedicated to create compact music ? Something which could be called "Minimal Tracker" or so ?
4) Do someone know how hungry are common tracker routines in sense of memory footprint and T-states taken ? Somehow i can't believe that all that demo coders were satisfied with routine which takes more than 15000 T every interrupt (i estimate that Pro Tracker takes about 20000 T).
Post edited by Fikee on
Comments
Adding functionality for a second (or third) channel, rests and hardware envelopes comes fairly cheap if you want to use them. Some sort of loop control will probably help you store your songs more efficiently too.
I'd reckon that it ought to be possible to do the above in a few hundred bytes and less than a thousand t-states per interrupt.
On the other hand, if you need things like pitch bends, software envelopes, arpeggios and percussion you're probably best off sticking with a tracker for the moment.
I'd be surprised if ProTracker used that much time to play music. Head over to Sergey Bulba's webpage (bulba.untergrund.net) and you can grab his PT3 player... it lists the min/avg/max time to play each "frame" of a few tracks. I have a version which if marginally smaller than Sergeys (I removed some unnecessary stuff), but it comes in at 2125b.
...Actually, I have Sergey's player with me - here's the time for various tracks.
That'll be Apology - not particularly useful for this topic, as the tracker there was written to handle one special case (6-channel sound, no effects, just one big list of notes really).
I seem to remember that someone from Russia (possibly MMCM / Sage?) was working on a minimal tracker a few years back - actually called Minimal Tracker. I didn't look at it (not sure if it was ever finished, in fact) - normally my music for <=4K intros (of which Haiku and my latest effort Starlet Guitarlet are the most notable) is hand-coded in assembler.
As aowen says, doing it that way means that you only have to code in the effects you actually use, but for Haiku I ended up implementing pretty much the entire feature set of SoundTracker. There were two major techniques I used to save space: firstly, expressing samples as changes over time (so rather than storing it as 15, 15, 14, 14, 13, 13, 12, 12... store it as "begin at 31, decrement by 1 each time (and shove an SRL A instruction somewhere in the player code)").
Secondly, and more importantly, exploit the hell out of self-similarity and repetition in the music. Trackers do this at a very basic level, by dividing the song into patterns which are played back in a defined sequence - some of them, like SQ Tracker, go a bit further by having individual patterns per channel - so if you have drums that just keep going bum-tish ba-dum-dum tish, you can just have one channel playing that one pattern all the time. You can take this a lot further though - for example, the opening theme of Haiku has three bars with a different melody but exactly the same rhythm, so it makes sense to treat the "rhythm pattern" and "pitch pattern" as two separate things, where rhythm repeats and pitch doesn't.
(Actually, the accepted wisdom handed down from the PC demoscene is *not* to explicitly code the repetition as a loop - just have lots of long repeating data streams, and let your packer deal with them. This may or may not be helpful, depending on what you're optimising for - runtime size or packed size...)
The master plan for Starlet Guitarlet was to take this to the extreme - I was covering a dance track, so obviously there's going to be a lot of repetition, and if you analyse it closely there's a sort of fractal nature there - repetition at lots of different levels, right from the overall progression of the song down to the makeup of individual notes. I was hoping that once I'd effectively decomposed it into a sequence of sequences of sequences of sequences of sequences of sequences of AY register writes, I'd be able to pick out a pattern in my code that would represent "sequence-ness", and I could work out a way to say 'do this thing 6 times'. Unfortunately, time and space constraints meant that I didn't get that far...
I don't know where I'm going with this really. :-) I suppose my point is something like this: trackers do a pretty damn good job of dividing music into repeatable building blocks. People can do an even better job, because the brain is very good at finding patterns. Trying to do this automatically is hard. Interesting, but hard.
Well, actually the program is here:
http://trd.speccy.cz/system/MIN_X.ZIP
http://mister_beep.republika.pl/
As far as being worried by the memory footprint of modules... well.. it bothers me a little, but then I just stick it in a spare 128k memory bank and forget about it
..and on the subject of writing music that takes up only a small amount of space - embrace randomness! IIRC the whole player code and music data for some of my 1k intros is only a couple of hundred bytes long when compressed, and the melody data comes from the Spectrum ROM - it's all about taking "random" data and being able to bend it into something musical using a simple ruleset
Eventually I wrote my own simple routine. It uses only one channel at constant volume.
The results can be seen here:
http://www.worldofspectrum.org/infoseekid.cgi?id=0018326
If you like, I could send you the game code.
Sad. Very sad but true.
Metallica will sue me.
http://mister_beep.republika.pl/
Years ago I have written my own player and compiler for the polish ProTracker (1.1 it was, I guess). Later I found the ProTracker was originally accompanied with a compiler of their own, it just didn't found its way here as someone didn't suppose its important enough to pass it along.
My compiler was basically doing things which gasman mentions, converting the pattern structure suitable for editing to the program-like streams commonly used in all pre-tracker players.
The result can be seen for example in Xor 128, which I have implanted with a compiled version of one of the demo tunes which came with the ProTracker.
I might even try to find some of the sources if you are interested, although I would expect that people today use one of the more advanced trackers instead anyway.
Patrik
If Polish then SOUND-Tracker (yes, 1.1).
ProTrackers are Russian.
http://mister_beep.republika.pl/
Patrik
It's not a tracker, but there might be some bits that you can nick - the full source code is included ;)