Search options (Page 3 of 21)

That's actually the routine that goes under the 'Tim Follin 3ch' title in 1tracker, added there good 11 years back. To my knowledge, no one ever used it for a song.

It is a three channel engine that has a specific limitation in that three channels share the same exact note length and 'volume' (duty cycle) envelope. I.e. you can't play a long note and a number of shorter ones at the same time. It is also prone to very severe detune, so all note combinations has to be tuned up by the ear to sound properly.

I honestly can't wrap my head around the internals of the 5/6ch engine. Very complicated design for the time. Hopefully FrankT will figure it out.

There is no limitation in the engine. Import allows to import up to 64 frames worth of sample data per drum, which is 2048 bytes (16384 1-bit samples).

Thanks, utz! Now we certainly need to get some good use to at least some of your developments.

Meanwhile, fixed the 128K problem.

From your description it kinda sounds like your emulator works in realtime for some reason. Normally an emulator does not run in realtime, it executes a chunk of code worth of a frame clocks, all sound writes just get queued with a timestamp in the emulated system clocks. Then it get synced with the realtime - a frame buffer displayed, the queue rendered and downsampled into a sound frame (~882 samples at 44100 Hz) that can be either streamed to the OS audio or dumped into file.

A filter is not a problem per se, just a low pass filter applied to your sound stream rendered at the system clock (8000000 Hz), so you get rid of the high frequencies before downsampling (this called pre-filtering), then downsample it to 22050/44100/48000 etc, with something better than linear interpolation preferably. The tricky part was usually how to do it efficiently, although I don't think it is a big deal for the modern PCs.

Thanks!

Will look into these issues.

Oh, silly me, I just lost one line that is needed to make the tempo compensation work, when I was replacing the sample routing. Updated archive is in the first post.

P is 'pitch'. It is not really pitch per se, more like a filter of sorts, makes the sample sound more and more muffled. On some samples it actually feels like a slight pitch change, though. O is sample offset, a sample can be played not just from beginning, but starting from a later point, it helps to get more dynamics with the same sample.

RLA gets the topmost bit into the Carry after a logic operation XOR/OR/AND that normally does not affect Carry. Honestly, I forgot that I ever invented this method (perhaps borrowed it from you?).

Oh yeah, dithering applied to the 1-bit sound synthesis may bring some quite interesting results! Cool idea, never thought about that.

I still can't get rid of suspicion that AngelScript just does not happen to be very stable. Especially between platforms. Too bad it is too late to switch to something, and, well, back then I picked it because it shown very good speed among other script engines, plus it had C-similar syntax. These days Python would be a better bet, I guess, but alas.

Wow. Maybe I'll just rework all the engines and interfaces to avoid the use of uint altogether, so it'll be int all around? I wasn't ever getting any segfaults or crashes under Windows, though.

Oh yeah, loopRow seem to be uninitialized in one of the branches in many engines. Damnit the mindless copy paste of seemingly working framework.

Assembler is intended to be called only once (function ZXStandartExportOptions in zxspectrum.1tl), but the assembler itself is a multi pass, not a single pass one.