Music - Again about Pro Tracker 3.x players

Again about PT 3.x players
Alone Coder 

 A collection was published in the last issue─
nickname of short players by Sergei Bulbabut 
this is not the last page in the history of PTZ
players. I took the player from Dr.Lion/RSMand 
made a custom player based on it
the size of which in most cases is not
exceeds one kilobyte.

                  * * *

   Let's dive into history.

   Pro Tracker 3 by Nick/Golden Disk
Corporation, which appeared in 1997, was 
a worthy continuation of previous versions
Pro Tracker from the same author. 
  As you can see from the then popular op─
rosniks in newspapers and release statistics, in
those glory days, the era of 48K computers
we were just ending, and what appeared
the room for maneuver seemed endless─
for them - 128K, and for many more! (Otechest─
military Spectrums that had a built-in 
AY boxes usually had more 
memory, but it was usually sacrificed for the sake of owls─ 
capacity, but only drivers for it─ 
just appeared.) Himselfthe editor demanded 
128K. Yes, and it was supposed to go to the music─
put a whole page, not a piece of 48K memory,
as can be seen from the default compilation address
(#C000) :)
   Original Pro Tracker 3.1a (and 3.31)
had a built-in compiler with a player once─
measure#E21 bytes (3 and a half kilobytes).
 The player had a typical structure from the present─
a swarmer, but he was hardly expected
use with multiple tracks, because
which of the two frequencies available in the editor─
any tables in the player could be used every time─
use only one, and when starting
the new Mouzon player was not initialized
completely (I usually got around this by specifying
in the first note of the track there is an instrument, an ornament and
volume).
   The player had a critical error in the image
team botbxxx (vibrato), but this coma─
ndu was used by few people in music; also
there were a couple of small errors in the command
Зxxx (portamento) - one in the compiler
(concerned the compilation order, so that when
transition of portamento across the border of the pattern─
new parameters were calculated correctly at least
for unique patterns), another in the player
(it was necessary to take into account the gliss). According to rumors
the editor was written by the author in the army, and after
service, the author never returned to the stage.

   In 1999-2000 Sage Groupin the face
Mm#D86
byte with functionality that is basically identical
original. Source code of the editor from the guys
there wasn't. The editor himself corrected MmXXXX_I1.H - and a utility for 
track preparation -CON_A.H .)
 Work on the editor was completed in
connection with the emergence of the Sage Group project
Minimal Tracker. 

   At the same time, among publishers electron─
solutions for
using one player with two hours─
total tables. The main idea is the address
the table in the player is known, it can be under─
change not with the player itself, but with an external program─
frame. Such a player was made at one time and
I. Such players were also needed in system
programs.

   Istarted adapting Pro Tracker in 2001
year, initially in order to add
mouse support. I ended up decompiling
editor, released several dozen versions─
this, where I fixed a number of problems (including
restrictions on tempo and pattern length),
added a total of 38 hot buttons (oh
how they are missing in Vortex Tracker!) and
many different features, including shift
ornament without changing the envelope, "transparent"
envelope input, copying with overlay,
"transposition" of volume, Merge module and
TurboSound support.
   Based on the source code from Sage Group, I made two
player: "fast" (fast, like the original)
and "mic&rc" (short, slow at peak, but
fast on average). "mic&rc" went to the system─
ny programs, "fast" - to the rest. Both
players were significantly shorter than the old ones, but
the most important change is that
that they are CUSTOMIZABLE, including the possibility
enable support for all 4 frequency tables
at the same time. Commandbxxx has been corrected,
in the latest versions it was, as far as possible,
The command Зxxx has also been fixed. Both teams
you can simply turn it off in the settings, if
This makes the player shorter and faster.
The original limitation on
pace. If the temp is below 3 it was impossible before
use at all, now with the player
"fast" is now possibleuse tempo 2 and 
with the player "mic&rc" - and tempo 1. Limit─
tion was due to the fact that parsing musical notation
The text flowed through one channel per frame. My
the "fast" player could disassemble at tempo 2
two channels at once. And the "mic&rc" player was broken─
I immediately grabbed everything that freed me from the need─
bridge a bunch of variables (this is why
On average it is even faster than "fast").
   These new players were based on Mac─
dews, which made it possible to correct the code in all
channels simultaneously. Use in these
macros of parametric marks (especially
ALASM) for a long time did not allow co─
compile them in cross-assemblers. By the way─
Yes, I was recently able to tame SjAsmPlus, and
using rather clumsy designs
the "fast" player now compiles there
(look in the appendix).

   Time passed, and at one point
users said that the compiler is in re─
They don’t need a daktor, increasing memory under
the module is more important. The fact is that the module com─
is copied to the same page where the code is located
player, and if it goes beyond its limits,
it cannot be unloaded correctly. It was
especially relevant after I died
reduced the number of patterns from 42 to 48.
   To compile with convenience, I wrote─
sal the PT Util utility. Besides the compilation there
there is also decompilation and pattern sorting
and channels, but the most interesting thing was
in the player!
   What's the idea? Player in PT Util (descendantmic&rc ) has no initialization. She's acting─ 
It’s definitely not needed if you’re compiling ple─
yer under one track. Just one point needed
entry - play one frame. In addition, in
the track can store non-relative addresses─
sa, and absolute ones - this saves memory,
and time. The win was huge - the player for─
took only#900 bytes.

   And then a new step took place - in 2004
Dr.Lion/RSM for his part and Sergey 
Bulba, for his part, made players, 
which do not have a procedure for every ka─
cash, but all channels play with the same code, using─
using index registers. History is not dry─
wounded, as player Sergei Bulba wrote, but
Dr.Lion made a player based on "mic&rc", 
replacing the already mentioned parametric me─
in macros for calls to(IY+d).
 Dr. Lion's player could not boast
extensive documentation and quiet for a long time
was in the Pro Tracker source code... for now
The time for 48K demomaking has not returned.

   At that time I had already suffered while packing
demo New View 48K with player from Sergey
Bulbs (occupies memory#86E bytes from uka─ 
the instruction states that the code weighs only
#651 ), and decided to find out: what are we, our own─
really, we still have at the moment, and what,actually, prospects?
   And we have...#bCE bytes from a modest
Dr. Lion's, more than half as long 
original! I completely forgot about this one
player, although it was lying under me all the time
nose. And not just the shortest player,
but also the most read!
   I feverishly sat down to study the code on the way
translated the comments into English and replaced─
nil numbers in(IY+d) on the labels. How it all became
simple and clear!
   The player was shortened by replacingiy with hl
in some places, removed initialization.
A couple of hundred bytes in your pocket. I moved on.
Added settings for throwing out commands,
like in my players. I started checking for
collections of different tracks. Since The
Compo I knew that you could write without commands 
in general (I threw out all the commands)
and without accumulations in samples (as usual
music is compiled into the Info Guide).At the same time
included the removal of the envelope shift in the sample─
lah (fortunately, some don’t even know that in
PTZ is such a possibility) and noise shift in 
pattern.
   What if you cut off the title of the song?
(first 105 bytes)? It is also used─
only during initialization, but the player is not needed!
Cut it off. From this moment the length of the player
count as block lengthplayer+module, mi─
nus the length of the original module (otherwise pro─
your head will crack).
   What if you remove the volume table?
After all, you can write under a linear table!
Pro Tracker is compiled under this left 
little finger (one such version is PTЗ.7Зli,
it is in the attachment along with the full ar─
archive of text documentation). I don't know on─
Vortex Tracker's score - in any case,
using hacker methods the table in his body about─
is detected (for example, in version1.0 beta18
- from addressOxBE2A8 ). In general, I did that too─
what setting.
   What if we shortened the frequency table?
Ummm... So as not to worry about recalculating the hour─
hundred, made a nibble of the beginning and end
tables - as many notes as the user wants.

   Get ready...

 #23B bytes on the test song. 571 bytes!

   I remember the words of one fidoshnik, who─
who promised Mednonogov to drive music out of 
5 to 2 kilobytes if he does not have enough memory 
- if only he finished Black Raven 2... 

   But this is not the limit - we are not there yet─
got the module format :)

                  * * *

 Finally, about how to write (or
work) module so that when using it
was lessproblems.

               By size:

 1. Most of all, music with black─
by increasing the tempo. Most often the two alternate
meanings. In many cases this can be done
avoided by removing every second line─
chku (if pauses are used there, then we can─
but add copies of tools with pause
or use the command vibrate(bxxx) ).
Vortex Tracker does not have tools for deleting─ 
every second line, you can do this
in Pro Tracker (clickChannel, then ss1 and
further stompcsO ). This is how we managed to “rescue”
Moran's track "ZX-HypnoPUNK", which even
was not unloaded from the editor due to size.
You can save money in other ways - extra─
rive automatic tempo switching
the player itself.
 2. Identical channels are encoded the same
times. If you have a repeating drum line
except for the end of the pattern, cut off
this end of the pattern is in all cases from─
efficient pattern.
 3. Noise offsets are registered in the channel
B. If you use them at the same 
contents of channel B, there will be an extra copy
thischannel. You can not use them at all─
Well, the player will become shorter and faster.
 4. You can save on tool tails─
tov, if these instruments are actually played
not completely.
 5. Accumulations in tools are really good─
relevant only for long, looping instruments─
cops. If you have debugged the sound, you can remove
accumulation. If the number of lines in the instrument─
ment has not changed, then this is a net gain
in the size and speed of the player (setting
smpfix).
 6. If the envelope is sounded in two channels,
then in one of them you can skip the type
envelope (it is enough to register it one
times). At the same time, there will be no extra time─
The envelope period is displayed (2 bytes).
 7."F" should not be written before the ornament number
required (starting from PTZ.69). This is economical─
allocate one byte for each such note.
 8. You can often save on writing
volume (often setF), if appropriate─
edit the instrument accordingly─
cops.
 9. If you can avoid commands throughout
song - do this. It can significantly
shorten the player (and in the case of gliders and vi─
brother - and speed it up). In the player you can select
grow each individual team or even
everything.

   By playback difficulty (measures):

 1. In most cases, the question is about
maximum playback time. It
most of all while reading notes with a bunch of
parameters and command (notes in different channels─
lah are not read at the same time, so opt─
It is the individual notes that need to be mixed).
Portamento processing also takes time.
and vibrato while they last. Best bu─
children, if your song does not contain co─
mand (this will save the player from the code, considering
slides). Unfortunately, existing
editors do not allow automatic re─
write any sound behavior from a pattern in
tool.
 2. Non-use of savings in instruments─
ment shortens and speeds up the player. This
regularly used in the Info player
Guide. Unfortunately, automatic reversal─ 
I don’t have a savings account, I do it by hand─
no.
 3. If you do not use shift envelope─
cabbage soup in the tool, then report it
coder (this is very difficult to understand by eye).
Usually this is only needed for vibrating
envelope. Removing this functionality fromThe player shortens and speeds up the player.
 4. Temperatures below 3rd sharply increase ma─
maximum playback time.
 5. The player for TurboSound takes two
times longer than playing one─
th AY. If you put this kind of music into re─
hysters, it may take several pages
to music (for example, in Nedodemo 2 music
took 4 pages). This holds back the practice
ical use of TurboSound.  But he
would be a good fit for 3D demos where there is a frame─
The truth is not important.

   Real playback issues:

 1. Command Зxxx on the same note or with sha─
gom exceeding the distance between notes.
These simply have to be removed.
 2. Tone shift with commands 1Oxx, 2Oxx - by─
is not supported in players (but there are three of them─
there are no cows yet).
 3. A song usually longer than 14 kilobytes
nowhere to put it in memory...