next gen engine ideas (Page 2 of 6)

Discovered a new trick while working on Houstontracker. Consider the usual pulse interleaving with variable duty cycle:

   add hl,de
   ld a,b          ;b = duty
   cp h
   sbc a,a
   out (#fe),a

   ;blabla same for 2nd channel

Now, as you know, we can add a "SID-style" duty cycle sweep by incrementing the duty when the add counter (HL) overflows.

   add hl,de
   ld a,b          ;b = duty
   adc a,0
   ld b,a
   cp h
   sbc a,a
   out (#fe),a

So far, so good. Now for the new stuff, we'll add an extra parameter that will be XORed against the duty setting on every sound loop iteration.

   add hl,de
   ld a,b          ;b = duty
   adc a,0
   xor c           ;c = additional XOR parameter
   ld b,a
   cp h
   sbc a,a
   out (#fe),a

This will produce some very interesting timbres! A primitive form of square wave FM, if you will. The result tends to have some aliasing noise (because the harmonics will cross the Nyquist limit if I understood this correctly), but I suppose it could be filtered out with the low-pass filter algorithm I was talking about earlier.

Now I actually went another step beyond this. Since I'm using a split timer update as usual, I have time to add an offset to the XOR paramter (C) every 256 sound loop iterations. Now this is a double sided sword - it will act nicely as a third FM OP, but only if the value is 1/256th of the base frequency used. When it is not, then the results will vary from "interesting" to "ouch my ears".

The attached .tap demonstrates both techniques. The first pattern starts with a simple duty cycle sweep and the additional XORing disabled, followed by XOR parameters of 8, $10, $20, $40, and $80. The second pattern starts again with regular duty cycle sweep and XOR 0. Following this, the XOR parameter is raised by 1/256th of the base frequncy once per 256 sound loop iterations, and following this the XOR parameter is raised by a fixed value (8 in this case) every 256th iteration. This is then repeated but with the initial XOR set to $80.

Don't ponder too much about the code in the .tap, there is some additional leftover stuff from an earlier experiment.
Anyway, I'm busy with HT at the moment, so if someone wants to pick up this trick in the meantime, be my guest

EDIT: Realized I posted this in the wrong thread, moved for clarity.

Oh, I better hurry up with turning this into a proper engine then, eh?

Did you manage to solve the aliasing problem that comes with this approach, and if yes, what was your solution? I'm thinking to use a simple low-pass filter like the one I described earlier, not sure if that'll work out though.

So I was curious whether it's possible to combine Shiru's Phaser technique with zilogat0r's Squeeker method. Turns out it works surprisingly well!
The downside is of course that the sound is somewhat less clean than with proper pulse interleaving. But there are various benefits to having only one OUT in the loop. It's not only faster, but also there's no need to keep the cycle count down because there's no need to render multiple volume levels.

I'm not motivated to turn this into a proper engine at the moment, since it would be impossible make an XM converter for it anyway. But if anyone wants to play around with this, please do!

EDIT: Added the good ol' adc a,n SID and Earth Shaker effects on channel 1. Because, why not. This brings the total of configurable parameters for the first channel up to 10:

- frequency OP1
- frequency OP2
- duty OP1
- duty OP2
- SID on/off OP1
- SID on/off OP2
- ES duty modulation OP1
- ES duty modulation OP2
- Phase
- Mixing method (xor | or | and)

All nicely aligned to 224 t-states

The next step could be to add some modulators which would update the parameters once per 256 loops or so. Or maybe digi rendering with lo-pass... ehhh... I've got a strange feeling this is getting outta hand...

I wonder if there is any useful 1-bit application to this trick: generating saw wave just like we generate different duty cycles. I.e. we have 16-bit accumulator and adder - add hl,de; this automatically creates 0..255 saw waveform in H.

I've made a simple engine like that last year. Example here (not optimized for contention whatsoever). Schematically it uses a number of routines like this:

.lvNN
    ld a,#C0
    add hl,de
    and h
    exx
    add hl,de
    add h
    rra
    rrca
    rrca
    and #38
    ld (.lv_jmp),a
.lv_jmp=$+1
    jr $+2
.lv00
    ...
.lv01
    ...

interspersed with OUT (#FE),A and such like

As far as efficiency goes, it depends. With wave tables, you're doing additions on table values, one addition per each channel. This method OTOH allows summing up 'the H's' themselves first and then derive the resulting level from that, so in the end it's probably more or less the same thing

I tried to illustrate the way the channels are calculated alone, throwing out loop counters etc. In the actual engine, there's only one .lv_jmp JR, which is located near the beginning of the loop and preceded by the fixed-position OUT. There's two OUTs each loop iteration. The placement of the second OUT varies according to the .lv routine (this is the only difference between them), i.e. each .lv routine sets a certain 'volume level' using PWM. Logically, they are divided into intervals of 11-13 T states for this purpose, made up from just what's in there, hence why it's so noisy esp. on contended machines. Overall there's 8 'levels' like that, each of the channels uses 4. I don't remember the reason for double-digit label naming, probably had 16 levels in there at some point

I was figuring out how early digital analog synths (i.e. with digital oscillators) were working, I always wondered why they only had saw, pulse, and a combination of those, but not some other waveforms (triangle, sine). I thought that is related to the richer harmonic content the two gives, but it turned out in my experiments that a combined pulse/saw generator can be implemented as simple as add hl,de, so that's likely the reason. It naturally gives the saw waveform in the MSB, and putting a threshold on it (with cp N) gives pulse with duty cycle control. We're using the latter quite often, but maybe there is some use to the saw itself too?

I tried a naive approach, use top 4 bits to generate a short pulse of different width every loop, sounds bad and not usable.

Ok, here's another, rather wild idea: Could this be of any use? Rui Martins once showed me an almost-working implementation of it, which operated on signed, range-limited PDM wavetable data. I never fully understood how it actually worked, though. It had problems in any case, mixing was unreliable. I'll see if I can get Rui's permission to publish his code here.

Hmm, in its current form it burns a lot of registers for the buck, I'd say. But generally speaking, anything that does pitch slides is always interesting. Do you think there's any chance to turn this into a vibrato effect somehow?

Meanwhile, I got permission from Rui, so find attached the source for his "WPDM16" player. A few notes:
- main.asm is the latest version. It does not attempt full PDM mixing, but rather a simplified version thereof.
- main_old.asm is an earlier version. Not sure if this one is working at all, so I include it mainly to illustrate how the player developed over time.
- Sample data should contain only signed offsets from -64 to +64. However, as I mentioned mixing is unreliable, so I created some samples that would mix with reliable results, but violate the specs.

Yes, but then again vibrato via table lookup sucks for two reasons: One, it burns a load of cycles. Two, fixed offsets are not so useful - for a good vibrato, the frequency shift should ideally be calculated as a fraction of the base frequency. A more elegant solution would be nice to have. Though I don't see how at the moment, I'm having enough trouble pulling off normal one-way slides already (finally managed a somewhat acceptable solution in Betaphase, which is similar to what you use for synth drum generation in Phaser2 I believe).

utz,

this is very interesting, I have been (too) busy elsewhere, but trying to follow what's going on here every day.
I am going to make some tests with this engine, looking now to ASM-files, especially music.asm, apparently need to look Phaser and Squuker methods as well, for the tunings, methods (1+2), shaker (?)...

Thanks of great job utz !!