Search options (Page 13 of 41)

Hi Jumperror, welcome to the forum. Wow, you're doing a lot of cool stuff! Glad to have you aboard. Looking forward to hearing more 1-bit (and other) tracks from you. I'm curious what you could come up with on some of the newer beeper engines. If you have any questions feel free to ask anytime.

Great little tune. A pity that CAFe didn't have a dedicated beeper compo though. Hmm maybe next year...

Aye, it took a while for ye olde brain. I was fixated on the "volume control" part, but it's really all about the harmonics, right?

In that case, a word of caution: Emulators are often misleading in that respect, actual hardware can sound quite different. Generally 48k tends to be more noisy, and harmonics tend to be buried under the noise. Anyway, if you're going to explore further in this direction, I can help with some hw recordings.

The question remains where these harmonics come from in the first place. Is it because at these marginal pulse width threshold overflow errors from the frequency calculation become more significant?

When I worked on those multi-core engines with many volume levels, I also noticed another effect. If there are several consecutive frames with high total volume (mimicing a DC offset), some sort of volume ramping will occur, gradually turning rectangular waves into saws. Octode2k16 is perhaps the best example of this. I tried to control this effect but it was very unreliable. Still wonder though if it can be used somehow.

Hi Dave,

In general you should be able to get away with LD ($6800),A. The thing is that, because of some hardware quirks, on the Spectrum we try to align all writes to port $FE to a multiple of 8 t-states for cleaner sound. Chances are you don't have such a requirement on your machine, so you can get away with shifting the timings a bit.

There is another problem here though. The engines that use this type of "output-and-rotate" approach heavily rely on the fact that the Speccy only looks at bit 4 for the output* and ignores the other bits. So writing the value of A directly to ($6800) probably won't work. You'd need to check bit 4 of A each time and set the output accordingly, or perhaps you could look into changing the sample format so it better suits your needs. I think if you changed the sample values as follows:

$88 -> $11
$cc -> $99
$ee -> $77
$ff -> $ff

things might work out.

* that's a bit over-simplified. Bit 3 also has an impact but often that fact is simply ignored.

Thanks mate Good idea about the track listing. Gotta find my yt password first, though

Live @ Chipwrecked 2019:

https://www.youtube.com/watch?v=CtNVPV0DNeQ

Enjoy

Video recording by N3M3515, I wholeheartedly recommend checking out his stuff if you're into heavy chip metal.

Ha, nobody expects the Spanish Inqui... I mean this new trick I discovered!

So basically I found a way to approximate a sine wave with just two square waves. Which means it's cheaper to implement than what Pytha uses to generate the triangle wave. Quality isn't as good as Pytha (mainly due to the fact that it seems almost impossible to properly align outputs to 8t multiples), but hey, how about squeezing in a 3rd channel? There's also some sweet overtone tricks you can do with this, as can be heard at the end of this short demo track. The third channel is a regular pulse channel with duty cycle control/sweep. Was hoping I could do 3 sine channels but I ran out of cycles. Either I'd need an extra register pair, or I'd need to split frequency counter updates across two loop iterations, which would probably degrade sound quality quite a bit. Overall the technique seems to be less flexible than the Pytha method as well, but I haven't explored it all that much yet.

So, here's a test modified to use CARN, for comparison. The test implementation will occasionally produce errors (manifesting themselves as short blips), but other than that it sounds quite alright to my ears as well

The great thing is that since there's one variable less to track, CARN can be implemented in less cycles, which is always a plus. But both COVN and CARN obviously have their uses considering the differences in sound. So ideally I'd want to come up with an implementation that allows switching between the two at runtime. I'm sure it just needs a nice piece of self-modifying code Only problem, as mentioned, I'm out of practise as far as assembly coding is concerned, but I definately want to get back to this and produce a proper engine.

In the first test example, there may be some additional problems in addition to the bad RNG. Also, the pulse density is actually fairly high in both examples. The envelope in the COVN one starts with a window size of 9 and goes up to 129. For CARN, the envelope starts with numbers < 8 and goes up to numbers < 256. In any case, the random number sequence is actually not random at all, since I'm using a fixed seed for the PRNG. If you are interested in studying the characteristics, the sequence is calculated as follows:

// for COVN
// initialization
uint_16 seed = 0x2157
uint_16 state = 0
uint_8 window_size = x  // x ∈ {0x9, 0x11, 0x21, 0x41, 0x81}

// the actual generator
// as wasteful as it looks, it's actually just 3 bytes/ 19 cycles in Z80 asm - add hl,de; rlc h
uint_16 next = (state + 0x2157)
uint_16 temp = (((next >> 8) & 0xff) << 1)
state = (next & 0xff) + (temp << 8) + (temp & 0x100)

// by coincidence, this prevents two consecutive pulses colliding at the end of the current/beginning of next window
uint_8 next_pulse_delay = ((state >> 8) & (window_size - 2)) + 1

For CARN it's essentially the same, except that the window_size is replaced with a "range" value x where x ∈ {0x7, 0xf, 0x1f, 0x3f, 0x7f, 0xff}, and the pulse delay is calculated as

uint_8 next_pulse_delay = ((state >> 8) & range) + 1

The COVN example runs at 17412 Hz and the CARN example runs at 19662 Hz (actually slightly lower, because there is a short delay every 256 samples for updating the length counter, and there can also be some minor fluctuation depending on internal machine state). The window size/range is updated every 256*32 samples. There is an additional quirk: pulses across all channels will never coincide. If more than one pulse is triggered on the given sample, the additional pulse(s) will be delayed until the next sample(s). The tone channels always trigger a "double" pulse. I found this to yield a resonable volume balance. In an actual engine we'd want to make the pulse length variable for the tone channels to fake volume envelopes for those.

There are a number of different seeds that will work reasonably well, I'm just sticking to this one because I'm lazy and and it's the only one I can remember off the top of my head. Might also be worth lifting some ideas from Shiru's noise generator code to get better random numbers.

In any case, thanks for the detailed explanation regarding the spectral characteristics. I have to admit that the point in your paper where you start to talk about Power Spectral Density was about my brain switched off, especially with those scary-looking equations on page 4

Thanks a lot for the detailed explanation! It's all very cle... wait, so there's no backtracking involved, eg. the pulse location in window n+1 is independent of the pulse location in window n? If so, what's the difference between COVN and CARN, then?

Anyway, I'm just playing around with some naïve test code at the moment, assuming the above is true. It does sound noisy alright, even using my not-so-uniform el-cheapo XORshift. Computation takes 49 cycles, which is reasonable (though I'm cutting some corners at the moment). We normally can spend up to 224 cycles on the synthesis loop (a bit more when using Pulse Frequency Modulation), which will give use a sampe rate of 15625 Hz with the Spectrum's 3.5 MHz clock.

The attached example runs at 48.6 KHz, using a window size of 16 (so a density of around 3000 if I'm not mistaken). In any case it's just a quick&dirty test, more experiments to follow later. (It's a Spectrum tape file, so you'll need an emulator - I recommend Fuse if you aren't sure which one to pick).

Correct, we normally deal with raw clock cycles, though it's trivial to approximate the sample rate. Assuming the synthesis loop length is fixed (which is true to some extend for most existing 1-bit engines on Spectrum), and ignoring some hardware quirks, it's a matter of simply dividing the CPU clock speed by the number of cycles in the synthesis loop.

I can only speak for myself here, but I tend to think about it terms of samples in discrete time more often that not. It depends a bit on the platform - for example for PC speaker the latter approach might be more natural, due to how the hardware works. On Spectrum the common approach is to run a fixed-length synthesis loop, so it makes more sense to think about it in discrete time terms.

Don't worry too much about our terminology, it's not very formalized and everybody kind of uses their own terms. You'll probably know better how to actually name things than us most of the time. In any case, if you have any questions please feel free to ask, of course!

In any case, I have to thank you again for the great input you have been providing. I haven't been playing so much with 1-bit synthesis lately, mainly because of working on a new, experimental tracker, but also because of a lack of inspiration. Well, this discussion certainly brought back some of the latter If you have any more "tricks" to teach, please don't hold back! Generally any sort of signal processing with low computational requirements is of interest (never mind the "1-bit-ness" of things, it's possible to simulate multiple volume levels on 1-bit).

Been thinking a bit more about a feasible implementation. Since we have very tight memory constraints on our machines, ideally we'd want to generate the pulse sequences in realtime. However, I'm afraid the computation might be too expensive despite it not requiring multiplication. But since the pulse sequences are sparse, it should be possible to devise a format in which they can be stored efficiently after precalculating them - essentially we could just store the distance between the pulses. However, this would take away quite a bit of flexibility. Hmmm... my main struggle at this point though is still understanding how to generate the actual kCOVN/kCARN/kCTRN sequences.