MUZAK58 - Revision history

WiRe at 08:06, 12 June 2024

2024-06-12T08:06:19Z

WiRe: /* The Sourcecode */

2024-02-16T13:38:34Z

‎The Sourcecode

WiRe: /* Cascaded Sequences */

2024-02-15T20:32:26Z

‎Cascaded Sequences

WiRe: text has been revised

2024-02-15T20:23:00Z

text has been revised

Show changes

WiRe at 19:16, 15 February 2024

2024-02-15T19:16:25Z

WiRe at 19:08, 15 February 2024

2024-02-15T19:08:41Z

WiRe at 16:36, 15 February 2024

2024-02-15T16:36:12Z

WiRe at 16:33, 15 February 2024

2024-02-15T16:33:10Z

WiRe at 16:22, 15 February 2024

2024-02-15T16:22:03Z

Show changes

WiRe at 07:53, 14 February 2024

2024-02-14T07:53:19Z

@@ Line 73: / Line 73: @@
 [[Bytebeat]] is simply an 8-bit uncompressed audio wave stream at any fixed sampling rate, that is expressed by a single, more or less complex, mathematical function ''f(t)'', where ''t'' is the time represented by the number of the sample, which is also equal to the byte offset within the stream. It will start generating the first sample for ''t=0'' and will play the sample ''f(8000)'' after exactly 1 second if the sampling rate is 8kHz. Since this is actually a softsynth (music synthesis done by software), in theory any sound or music can be approximated in this way. There are no limits except the increasing complexity of the resulting function.
-In general, any bytebeat algorithm can be implemented to generate the next sample to be written to the COVOX LPT1. But in terms of size, a bytebeat algorithm is better suited if it's formula can be implemented in as few bytes as possible. [https://www.pouet.net/prod.php?which=96071 MUZAK58] is to a certain extent a generic or reusable background music player. Of course it is also possible to modify the player itself to change the music style (more on that later), but the source of the music played comes from sequence tables stored in memory. Changing these words will result in completely new music being played. If you use use more words for this table, the song becomes more complex so that it does not repeat itself so quickly. The sequence table of this reference example is 10 bytes long and looks like this:
+In general, any bytebeat algorithm can be implemented to generate the next sample to be written to the COVOX LPT1. But in terms of size, a bytebeat algorithm is better suited if it's formula can be implemented in as few bytes as possible. [https://www.pouet.net/prod.php?which=96071 MUZAK58] is to a certain extent a generic or reusable background music player. Of course it is also possible to modify the player itself to change the music style (more on that later), but the source of the music played comes from sequence tables stored in memory. Changing these words will result in completely new music being played. If you use more words for this table, the song becomes more complex so that it does not repeat itself so quickly. The sequence table of this reference example is 10 bytes long and looks like this:
 <syntaxhighlight lang="nasm">
    seqtbl:   dw      0x1413
@@ Line 158: / Line 158: @@
      return static_cast<uint8_t>(t / C);
+   }
 </syntaxhighlight>
 ([https://bytebeat.demozoo.org/#t=0&e=0&s=8000&v=circles&bb=5d000001007000000000000000003a028140b2901c8f2d314244236cb35b1c788f43a8bd95752d36006aa55dbc6cdcbeb9b5eebb4a5495e65c56d4efcd7d11ba349adaa5ca64f88abeeec07f8c411feb6be3fcc21580 listen to this bytebeat here])

@@ Line 208: / Line 208: @@
              popa                              ;61         ;  restore all registers (especially BX, CX, DX, SI)
-   suplp:   ;--------------------------------- ;---------- ;read 8253/8254 PIT ch#0 counter value (ch#0 must be reconfigured to 0b00010000)
+   main_lp: ;--------------------------------- ;---------- ;read 8253/8254 PIT ch#0 counter value (ch#0 must be reconfigured to 0b00010000)
              in      al, 40h                   ;E440       ;  read low-byte
              cmp     al, 148                   ;3Cxx       ;  did timer counter overflowed to 149..0FFh?
-             jo      bbeat                     ;71xx       ;    yes -> play
+             jo      short bbeat               ;71xx       ;    yes -> play
-  bbeat_sk: jmp     short suplp               ;75xx       ;  loop forever
+           ;... the place for your intro
 </syntaxhighlight>

@@ Line 125: / Line 125: @@
 But this limits the composer's freedom, you might think. This is true! But you will see that the results you get are not as bad as you might think at first, in fact the resulting limitation can even give new impulses to creativity; something we already know as the sizecoding effect.
-Here is an attempt to visualize how such an cascaded sequence will evolves over time, showing the sequence table index of 5 cascaded sequencers in relation to the sequence step counter. ''O'' is the time divider to derive the step count ''stepcnt = t / O'' with ''O = log2(ticks_per_step)'' to avoid any integer division.
+Here is an attempt to visualize how such an cascaded sequence evolves over time, showing the sequence table index of 5 cascaded sequencers in relation to the sequence step counter. ''O'' is the time divider to derive the step count ''stepcnt = t / O'' with ''O = log2(ticks_per_step)'' to avoid any integer division.
 <syntaxhighlight lang="text">
    +--------+--------------+---------------------------------------------+

@@ Line 136: / Line 136: @@
    | seq4ix | (t>>(O+4))%S | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 ... |
    +--------+--------------+---------------------------------------------+
 </syntaxhighlight>
@@ Line 162: / Line 163: @@
 = The Sourcecode =
-With all these parameters being chosen carefully, the final bytebeat implementation and sequence tables will become very small. Here is the documented source code of [https://www.pouet.net/prod.php?which=96071 MUZAK58]:
+With all these parameters being chosen carefully, the final bytebeat implementation and sequence tables will become very small. Here is the commented source code of [https://www.pouet.net/prod.php?which=96071 MUZAK58]:
 <syntaxhighlight lang="nasm">
             ;-----------------------------------

@@ Line 71: / Line 71: @@
 = The Bytebeat =
-[[Bytebeat]] is simply spoken an 8-bit uncompressed audiowave stream at any fixed sampling rate, that is expressed by a single, more or less complex, mathematical function ''f(t)'', where ''t'' is the time represented by the number of the sample, which is also equal to the byte offset of the stream. It will start generation of the first sample for ''t=0'' and, in case of an 8kHz samplingrate, will play the sample ''f(8000)'' after exactly 1 second. Since this is actually a Softsynth (music synthesis done by software), in theory any sound or music can be aproximated this way. There are no limits except the increasing complexity of the resulting function.
+[[Bytebeat]] is simply spoken an 8-bit uncompressed audiowave stream at any fixed sampling rate, that is expressed by a single, more or less complex, mathematical function ''f(t)'', where ''t'' is the time represented by the number of the sample, which is also equal to the byte offset inside the stream. It will start generation of the first sample for ''t=0'' and, in case of an 8kHz samplingrate, will play the sample ''f(8000)'' after exactly 1 second. Since this is actually a Softsynth (music synthesis done by software), in theory any sound or music can be aproximated this way. There are no limits except the increasing complexity of the resulting function.
-In general, any bytebeat algorithm can be implemented now to present the next sample to be written to the COVOX LPT1. But in respect to the size, a bytebeat algorithm is better suited if it's formula is as simple as possible, implementation-wise. [https://www.pouet.net/prod.php?which=96071 MUZAK58] is to some degree a generic or reusable background music player. Of course it is also possible to modify the player itself to change the music style (more on that later), but the source of the played music comes from sequence tables stored in memory. Changing those words results in an entirely new music tune being played. Also spending more words for this table will vary the tune, that it will not repeat as fast. The sqeuence table of this reference example is 10 bytes in total and looks like this:
+In general, any bytebeat algorithm can be implemented now to present the next sample to be written to the COVOX LPT1. But in respect to the size, a bytebeat algorithm is better suited if it's formula is as simple as possible, implementation-wise. [https://www.pouet.net/prod.php?which=96071 MUZAK58] is to some degree a generic or reusable background music player. Of course it is also possible to modify the player itself to change the music style (more on that later), but the source of the played music comes from sequence tables stored in memory. Changing those words results in an entirely new music being played. Also spending more words for this table will add ore variations to the song, that it will not repeat as fast. The sqeuence table of this reference example is 10 bytes in total and looks like this:
 <syntaxhighlight lang="nasm">
    seqtbl:   dw      0x1413
@@ Line 85: / Line 85: @@
 == Music Sequencer ==
-As you can read in many Bytebeat tutorials, like [[Steady_On_Tim]] by Gasman or inside the paper published by viznut, the basic idea to generate a melody with a bytebeat is to modify some basic waveform oscillator function ''o(t)'', like saw-tooth, square, triangle or sine waveforms, by multiplying the time parameter ''t'' by a scale factor ''p'': ''f(t) = o(t*p)''. This multiplication factor will modulate the pitch. If we then use a sequence table ''s(t)'' to replace ''p'', that will change the pitch of our oscillator over time, then we can already play some simple melody using this formula: 'f(t) = o(t*s(t))'.
+As you can read in many Bytebeat tutorials, like [[Steady_On_Tim]] by Gasman or inside the paper published by viznut, the basic idea to generate a melody with a bytebeat is to modify some basic waveform oscillator function ''o(t)'', like saw-tooth, square, triangle or sine waveforms, by multiplying the time parameter ''t'' by a scale factor ''p'': ''f(t) = o(t*p)''. This multiplication factor will modulate the pitch. If we then use a sequence table ''s(t)'' to replace ''p'', that will change the pitch of our oscillator over time, then we can already play some simple melody using this formula: ''f(t) = o(t*s(t))''.
 Accordingly, we implement a single pitch-modulated oscillator with saw-tooth waveform:
@@ Line 101: / Line 101: @@
 ([https://bytebeat.demozoo.org/#t=0&e=0&s=8000&bb=5d00000100250000000000000000141d0145bdb13c9159728aa3da7e69b2fed6480708c016cc4525c68500003024ed9dc1d9b391be7fffcfb76000 listen to this bytebeat here])
-Also other waveforms are possible here. Here we use the sine function:
+Also other waveforms are possible. Here we use the sine function:
 <syntaxhighlight lang="javascript">
    sin(t*[1,2,4,8,16,8,4,2][(t>>11)%8]/14)*127+127
@@ Line 113: / Line 113: @@
 ([https://bytebeat.demozoo.org/#t=0&e=0&s=8000&bb=5d00000100240000000000000000141d0145bdb13c9159728aa3da7e69b2fed6480708c016cc4525c68500003024f067719de4f113fffded5400 listen to this bytebeat here])
-'''HINT:''' Instead of using only one modulated waveform or one sequence, also 2 or more can be used and combined, like i.e.: ''f(t) = (o0(t*s0(t)) + o1(t*s1(t))) / 2''
+'''HINT:''' Instead of using only one modulated oscillator or one sequence, also 2 or more can be used and combined, like i.e.: ''f(t) = (o0(t*s0(t)) + o1(t*s1(t))) / 2''
-So far, this are well known techniques used in bytebeat algorithms. With this knowledge we can already start to implement a bytebeat player with one sequence table that holds as many steps ''S'' as we need for our tune, or at least as many as we can effort due to size constraints. The more steps ''S'' we spent, the longer the tune will durate before it repeats. The larger the value of each sequence step could be, with a value range limited by ''log2(M)'' bits per step, the larger the range of notes we can use in the end. Both parameters ''S'' and ''M'' will define the final byte-size of our sequence table.
+So far, this are well known techniques used in bytebeat algorithms. With this knowledge we can already start to implement a bytebeat player with one sequence table that holds as many steps ''S'' as we need for our composition, or at least as many as we can effort due to size constraints. The more steps ''S'' we spent, the longer the song will durate before it repeats. The larger the value of each sequence step could be, with a value range limited by ''log2(M)'' bits per step, the larger the range of notes we can use in the end. Both parameters ''S'' and ''M'' will define the final byte-size of our sequence table.
 == Cascaded Sequences ==
-The issue we will face with this approach in size-coding is, that such a sequence table will quickly grow and consumes quite a lot of bytes in the end. Our reference example here, [https://www.pouet.net/prod.php?which=96071 MUZAK58], spends 10 bytes for it's entire tune. If we take our knowledge at this point, then we would be able to use those 10 bytes to divide them into a sequence of 40 steps (''S = 40''), as long as the limited range per step given by 4 bits (''M = 2^4 = 16'') is enough for the music composition we have in mind. 40 steps is not less, but the heavily limited range of less than 1 octave will limit us to something that we would very likely call a children's song in the end. The reference tune instead sounds like being build out of at least a multiple of 32 steps, before it starts to repeat. And the octave range also does not appear to be limited to a single octave. What the hell is going on here? How is it possible to compress the sequence table in this way?
+The issue we will face with this approach in size-coding is, that such a sequence table will quickly grow and consumes quite a lot of bytes in the end. Our reference example, [https://www.pouet.net/prod.php?which=96071 MUZAK58], spends 10 bytes for all it's song data. If we take our knowledge at this point, then we would be able to use those 10 bytes to divide them into a sequence of 40 steps (''S = 40''), as long as the limited range per step given by 4 bits (''M = 2^4 = 16'') is enough for the music composition we have in mind. 40 steps is not less, but the heavily limited range of less than 1 octave will limit us to something that we would very likely call a children's song in the end. The reference muzak instead sounds like being build out of at least a multiple of 32 steps, before it starts to repeat. And the octave range also does not appear to be limited to a single octave. What the hell is going on here? How is it possible to compress the sequence table in this way?
 The trick discovered by wiRe here is to cascade multiple sequencers and combine all their output into a single sequence of much longer sequence duration (before repetition) and of wider pitch range per sequence step: ''s(t) = (s0(t) * s1(t) * s2(t) * ...) / C''
@@ Line 144: / Line 144: @@
 The basic idea is to design the bytebeat algorithm as a loop that performs the same operations on each iteration to achieve the smallest possible size. If we decide to use a simple saw-tooth oscillator, we have an easy game with our oscillator function beeing as simple as ''o(t) = t''. As we figured out, the function ''f(t)'' is then only comprised of ''N+1'' terms, all multiplied together like this: ''f(t) = (t * s0(t) * s1(t) * s2(t) * ... * sN-1(t)) / C''. On each loop iteration of the final bytebeat player, the current sequencer ''sN(t)'' is evaluated by calculating the current sequencer index and looking that up inside the sequencer table. The value stored there for this step is then multiplied to the total result of ''f(t)''. If we keep ''M'' low, then even a 16-bit multiplication is enough here. The final scale factor ''C'' depends on the range of the values derived from the sequencer functions ''sN(t)''. Scaling happens as a shift-right-operation in the last step. And with some tweaking of the sequencer step values can even be forced to result in a shift by 8.
-In the reference implementation, a total of 5 cascaded sequencers was used: ''N=5''. Each sequencer's table was chosen to store 4 sequence steps: ''S=4''. Which sequencer step to index is then based on 2-bits of parameter ''t''. The fastest sequencer step time was chosen to be ''2^10'' timer ticks or samples, giving us ''O=10''. This means the lookup index for each sequencer ''i'' with ''0 <= i < N'' is derived by ''(t>>(O+i))%S'', where O as start offset can be chosen different for each music tune. Each step value is limited by ''M=16''. Putting this all together, we can now start composing one music tune this way:
+In the reference implementation, a total of 5 cascaded sequencers was used: ''N=5''. Each sequencer's table was chosen to store 4 sequence steps: ''S=4''. Which sequencer step to index is then based on 2-bits of parameter ''t''. The fastest sequencer step time for this song was chosen to be ''2^10'' timer ticks or samples, giving us ''O=10''. This means the lookup index for each sequencer ''i'' with ''0 <= i < N'' is derived by ''(t>>(O+i))%S''. Each step value is limited by ''M=16''. Putting this all together, we can now start composing one song this way:
 <syntaxhighlight lang="cpp">
    static constexpr unsigned O = 10;

@@ Line 149: / Line 149: @@
    static constexpr unsigned N = 5;
    static constexpr unsigned S = 4;
-   static constexpr unsigned A = 256;
+   static constexpr unsigned C = 256;
    static constexpr uint8_t seqtbl[N][S] = { {3,1,4,1}, {6,6,12,6}, {2,4,2,2}, {5,9,4,6}, {4,8,4,4} };
@@ Line 155: / Line 155: @@
    uint8_t get_next_sample( uint16_t t ) {
      for( unsigned i = 0; i < N; i++ ) t *= seqtbl[i][(t>>(O+i))%S];
-     return static_cast<uint8_t>(t / A);
+     return static_cast<uint8_t>(t / C);
+   }
 </syntaxhighlight>

@@ Line 65: / Line 65: @@
 In general, any bytebeat algorithm can be implemented now to present the next sample inside register AL, as it is required by the previous example code. But in respect to the size, a bytebeat algorithm is better suited if it's formula is as simple as possible, implementation-wise. The method used to achieve a size-optimized, but still flexible bytebeat formula is described next.
-== Music Sequence Table ==
+== Music Sequence ==
-The basic idea is to design the bytebeat algorithm as a loop that performs always the same math-operations to achieve the smallest possible size. Following this concept, we break down the bytebeat function ''f(t)'' into ''N'' smaller terms ''gN(t)''. Then function ''f(t)'' is comprised of ''N'' terms multiplied together like this: ''f(t) = Π(gN(t)) = g0(t) * g1(t) * g2(t) * ... * gN-1(t)''. On each loop iteration of the final bytebeat player, ''gN(t)'' is evaluated and it's result is multiplied to the total result of ''f(t)''.
+(...more soon...)
-The function ''g0'' has a special meaning compared to the other terms, and will deliver the base waveform for the final music tune. To keep the code short, this function will deliver a saw-tooth or triangle waveform based on ''t'' and scaled down by constant factor D. Both can be implemented with very few instructions and scaling can happen as a shift operation in the last step. All other terms ''g1..gN'' will translate ''t'' into factors that will modify the frequency of this waveform. Those translations will be done through N different sequences, one sequence table per term.
+== Final Bytebeat ==
 Putting this all together, we can now start composing one music tune this way:
@@ Line 82: / Line 77: @@
    static constexpr unsigned N = 5;
    static constexpr unsigned S = 4;
-   static constexpr unsigned D = 256;
+   static constexpr unsigned A = 256;
    static constexpr uint8_t seqtbl[N][S] = { {3,1,4,1}, {6,6,12,6}, {2,4,2,2}, {5,9,4,6}, {4,8,4,4} };
    uint8_t get_sample( uint16_t t ) {
-     for( unsigned i = 0; i < N; i++ ) t *= seqtbl[i][(t>>(i+O))&3];
+     for( unsigned i = 0; i < N; i++ ) t *= seqtbl[i][(t>>(O+i))%S];
-     return static_cast<uint8_t>(t / D);
+     return static_cast<uint8_t>(t / A);
+   }
 </syntaxhighlight>