next gen engine ideas (Page 5 of 6)

Yes, was thinking the same thing. What I'd really want is to have some sort of an lfo-controlled lo-pass. A simple FIR lo-pass at a fixed cut-off is fairly easy to implement, but I haven't been able to pull off a variable cut-off in constant CPU time. Maybe could be done with another table lookup but I'm currently already short one register pair for implementing the second channel.

it has great potential. hopefully it will develop into something bigger.

trollolol

Oh wow !

Never heard sample playback that good before on the Speccy 48k :0

I've been toying with a very promising new engine design that makes it possible to use computation-heavy effects, while also eliminating row transition noise. I don't have time to develop this into a full engine at the moment, but I thought I'd share the idea in case anybody else wants to play with it.

The design revolves around using a crude scheduler to implement basic multi-threading. Within every iteration of the sound loop, the scheduler allots a fixed portion of the available cpu time to the main thread, which updates frequency counters and calculates the output value(s) for the next iteration. The rest is allotted to a variable pool of secondary threads, which run consecutively in between each main thread run. In other words, our sound loop consists of two parts - the first part is always the same and runs all those updates that are required on each sound loop iteration. The second part runs varying tasks that do not require fast updates, for example counting length, computing some effect, or reading in note data.

The scheduler is implemented by pointing the stack pointer to the music data, and then simply RETurning after the main thread. To keep the music data size manageable, we need to implement sequence loops and subroutines as abstract operations running as secondary threads. Ideally we'd do nested subroutines, however that's a bit expensive to compute and in some cases one could probably get away without nesting. No nesting basically mirrors the sequence/pattern approach we normally use. The following example would play two notes over and over again:

sequence
    dw set_note_ch1, some_note
    dw init_loop, #3fe     ; set note length
    dw jump_sub, delay
    dw set_note_ch1, some_other_note
    dw init_loop, #3fe     ; set note length
    dw jump_sub, delay
    dw jump_seq, sequence

delay
    dw do_nothing
    dw loop, delay
    dw return

Now, that may seem like a rather inefficient way to just do

seq
    dw pattern
    dw seq_end
    dw seq

pattern
    dw length, note
    dw length, other_note
    db ptn_end

Perhaps it makes more sense to pick a certain number of threads, and think of the time they will take as your refresh rate/tick length, eg.

    ...
    dw set_note, note
    dw init_loop, #80         ; 0x80 * 0x10 + 3 = 0x803 loops/ca. 8 ticks (so we can get away with just an 8-bit length counter)
    dw jump_sub, fx01
    dw set_note, other_note
    dw init_loop, #40
    dw jump_sub, fx02
    ...

fx01
    dw calculate_expensive_fx_part1
    dw calculate_expensive_fx_part2
    dw do_something_else
    dw jump_sub, delay11
    dw loop, l1     ; 16 

fx02
    dw calculate_other_expensive_fx_part1
    dw calculate_other_expensive_fx_part2
    dw calculate_other_expensive_fx_part3
    dw calculate_other_expensive_fx_part4
    dw do_something_else
    dw jump_sub, delay9
    dw loop, l1

delay11
    dw do_nothing
    dw do_nothing
delay9
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw return

Still expensive in terms of data size, but essentially we can now run things that we used to run in the outer sound loop (so, every 256*innter_loop_length t) at a much faster rate without affecting sound. This allows us to do stuff like fast&precise slides/vibrato and all sorts of variable-rate modulation effects. Also with recursive subroutines, you could actually have subroutines that generate subroutines... I think one could go pretty wild with this.

Neat idea, don't think we've used that anywhere yet.

I wonder if it could be pushed even further. Like, instead of every frame, add the offset at a variable rate. That could perhaps turn into a sort of 1-bit FM, without the use of PCM emulation trickery. (Sorry for hijacking your idea immediately, but I recently tried to implement actual FM again, and came to the same conclusion as last time: It's possible to do the necessary calculations fast enough, but the output is too noisy for reasons not entirely clear to me.)

I think that generally, pre-calc is a viable option. The number of unique notes in a song is usually not that high, so size-wise it's probably ok. More broadly speaking, pre-calc could open up quite a few new paths for beeper. We'd just need an editor that supports that *cough cough*

The alternative would be to, well, use a suitable modulator, which boils down to having one or more additional counters/oscs. Which is what lead me to the "scheduler" design I described above. The whole scheduling part is actually not that important. The core idea is to unroll the sound loop, say, 8 or 16 times, updating the main counters on each iteration and spreading out the more expensive computations across the various iterations. When using a 12-bit main counter, updating an auxilliary 8-bit counter every 16 sound loop iterations should give sufficient precision and speed.

My last, failed experiment uses something along those lines. It's running off 32 byte wavetables (which, in conjunction with an 8-bit main counter, gives a reasonable frequency range). When the aux counter overflows, a variable offset is added to the wavetable pointer, and the offset itself is negated. The problem is that my usual 16-32-64-112t PCM renderer is too noisy, so I would need to rewrite the whole thing using multi-core (ie, one copy of the sound loop for each volume level). It should be possible without duplicating all the "expensive calculation" versions of the sound loop, but eh... it's still a lot of tedious work.

Btw, I think I know what you mean re: maths now. It's often kinda tricky to know what the resulting perceived tonal frequency will be.

    di
    ld hl,0
    ld de,0
    ld bc,#180
    ld sp,#38+#180/4

.play_note
    add hl,bc

    ex de,hl
    add hl,sp
    ccf
    sbc a,a
    ex de,hl
    and h
    ld h,a

    cp #20
    sbc a,a
    out (#fe),a

    dec ixl
    jr nz,.play_note
    dec bc
    jr .play_note

Not going to pretend I have any idea what's going on here. Some interesting sounds happening though. Seems that the note frequency is actually determined by the value in sp, not the one in bc. Just resetting the phase without additional modulation in the outer loop does something rather Earth Shaker-y. inc sp instead of dec bc is fun, too. No idea how to make any practical use of all of this, though.