The AKG player is called “generic” because it is the default player you should use in your production.
It can play all the FM features of the song, but does not handle samples directly: it is up to you to play them. This player is the best compromise between power and efficiency. The songs and player are optimized both in speed and memory. This is probably the player to use in a game, as it handles long music very well. It also has a support for sound effects. Demos may use it, but cycle-accurate code won’t like it: it can not be stabilized anymore, or with great difficulty, because of the new effect management.
- Supports all the features of AT2 (effects, subsongs, etc.).
- Best compromise between speed/memory.
- Sound effect support.
- Can not be stabilized, due to its complexity.
- Rather large player (3kb).
CPU wise, it is hard to indicate how many cycles are spent by this player, but the average music goes from 25 scanlines to 35, on a CPC. This is slower than the AT1 player, but it is also much more powerful. However, add many effects on each channels and the CPU will rise skywards.
This player is quite complex, because of the possibilities of the instruments, plus the new columns of effects. This explains why the code is so large for a player. I struggled to find the right balance between speed and size, and sometimes decided to duplicate a few big chunks of code instead of having more generic code: the player would have been dramatically slower.
A few limitations are present in this format, but I believe no-one will ever encounter them:
- Only 255 Arpeggios are possible. “This is already the case in the editor”, are you going to say. Right, however, inline arpeggios (effects such as B37 or C37C) generate one Arpeggio (for each distinct value of course), so hugely complex music may generate too many Arpeggios.
- The generated effect blocks can only be 64k max. This is insanely big, so don’t ever pretend to break this limitation, I won’t believe you.
Can I optimize in memory?
- The player already has a few flags to discard some codes you may not need for your songs, such as the events management.
- You can remove parts of the code of the player you don’t need. It is quite easy to remove some effect management if you only use a few.
- The Glide effect is popular among musicians: it is also costly to manage on our little 8-bit architecture. If you don’t use it, a flag allows to ditch the code.
Can I optimize in speed?
The way your song is built has a huge impact on the CPU. Most of you won’t have to bother about it, but if your coder asks for a few CPU-cycles to save, here is what you can do for him.
Effects, though very handy, takes much more than using their counterpart within the instrument:
- For example, using the Arpeggio inside an instrument doesn’t cost much: using the Arpeggio Table inside a track costs more.
- The same for the Pitch Table.
- Glide effect costs many cycles! Prefer the simpler Pitch.
- The Reset effect is handy, as it resets all the effects. However, many flags must be reset, making it also quite costly. If you can, reset only the effects that needs to be reset. Most effect have their “reset” counterpart:
- Use A00 to stop the Arpeggio Table.
- P00 to stop the Pitch Table.
- Vf to set the volume to max.
- However, it is faster to use one Reset effect instead of two specific reset effects.