Search options (Page 20 of 21)

Finally, made my own demo track for the bundle: https://soundcloud.com/shiru8bit/overawire

The example sounds really cool.

Too bad I never managed to make the link cable to work, and I don't have a PC with COM port anymore.

I thought it is worth to add a simple visual explaination why exactly PFM (Pin Pulse, Narrow PWM) engines has weak low frequencies, why pulse interleaving does not have this issue, and how PFM is used to imitate volume levels.

Here is a graph of normal square wave of some duration. It has output high one half of the time and low the other half of the time. Let's count the 'cells' when the output is high, marked by orange. It is the output 'energy', or 'power', that is also percepted as 'volume'. 8 of 16 cells is 'active' here, this is max energy level possible for a wave.

Now let's take a square wave of  lower frequency and the same duration, and count the 'acitve' cells again. It is the same number, 8 of 16 - despite the different frequency, square wave maintains the same energy level.

Now let's take a 'pin pulse' wave of the same frequency as in the first example. See, there is just 4 cells 'active' - just a half of the energy that a square wave of this frequency would have.

And now let's see a 'pin pulse' wave of lower frequency, the same as in the second example. Just 2 cells 'active' - less than the higher frequency pin pulse wave has, and way lesser than square wave would have.

These examples shows that a pulse wave with duty cycle less than 50% yields less energy in lower frequencies, and this difference grows up as the duty cycle gets lower. 'Pin pulse' engines has very low duty cycles, like 1%, so it is very noticeable.

How to overcome this? One solution is to play a few desynced pin pulse waves on lower frequencies. This will give 'phasing' effect, but also will add more energy to the low end. Another solution is to make pulse width dependent from the frequency, increasing the width for lower frequencies. It is somewhat difficult to implement in Z80 sound engines, but a rough version of this is seen in the Special FX/Fuzz Click engine, which has one channel louder than another - that's because it just has wider pulses, and it makes it more suitable to play bass notes.

To begin with, it has been developed in ~1998 for Amiga, way before accuracy in emulators became important and even possible.

The main flaw of the format, though, is that it does not actually consider ZX Spectrum enviroment, i.e. there is no BASIC ROM in the emulated memory space by default, and most of beeper music players rely on having it in place. If you don't take it into account while ripping/converting music, it may easily get the drum sounds changed, or lost them althogether. Or, in worst case, all timings will be screwed up (Special FX/Fuzz Click engine has this issue), or code won't work at all (ROMBeep is an example). To make it work correctly, you need to include portions of the ROM into AY file, so you need to determine which portions actually used, which is not so easy, as to do this you need to understand how an engine works. Alternatively, to save your time, you can include whole ROM (in fact, if I remember correctly, it is not even possible, first two bytes will be missing anyway), and basically redistribute a copy of it with every AY file.

All this could easily be avoided would the format specs were explictly saying that memory space should have ROM pre-loaded (distrubuted with players, not with music).

There are other things that could be improved and cleaned up as well.

Yes, the HW only allows to set it to 0 or 1, so all sound code rely on this. Toggling, if needed in a particular code, is always done in software.

Does not seem much different, the same number of actions:

- Load .bbsong into Beepola
- Export WAV
- Encode into MP3
- Upload MP3

- Load .bbsong into Beepola
- Export .bin
- Convert .bin with a tool into .ay
- Upload AY

Also, with simplistic approach these AY files wouldn't be suitable for publishing, as each one would have to contain copy of ZX48 ROM, so they would only be useful as intermediate container for MP3 conversion.

I thought why not to actually put the idea I explained above to the test, so here is proof-of-concept. I wouldn't say it sounds better, but it gives somewhat different timbres.

Haven't look into the code, but an idea for volume control I had and never tried to implement is an evolution of what has been used in Tritone: mix channels by interleaving them, but change amount of time each channel takes. Time the code in a way that it does few outputs of each channel per one loop (or maybe few copies of the loop), and force some of these outputs to zero to attenuate the channel. I.e. we have channels A and B:

ABABAB full volume
ABAB0B mid A volume
AB0B0B low A volume

and so on.

Judging by the carrier tone that is heard in the test50.sna, is it something similar to the idea?

Here is a demo track written by theandroidvision. It only uses few plugins of the bundle, and does not have any extra instruments or processing: https://soundcloud.com/theandroidvision … o-vst-demo