26

(16 replies, posted in Other Platforms)

While a new version in the works, a small demo of what it is capable of (at least). I tuned up the sound synthesis code to match up the wtbeep's waveforms closely, so it was easy to port Freezing Point.

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

27

(16 replies, posted in Other Platforms)

Sure, I'm working on getting some demos made, as well as improving it even further. Don't have much time myself, but hopefully will do some music using it eventually.

28

(16 replies, posted in Other Platforms)

A new project of mine. A LSDJ-inspired tracker for a portable DIY device called ESPboy. The device is based on a cheap IoT microcontroller ESP8266, which is quite powerful (up to 160 MIPS), yet limited in the resources compared to many other similar devices. It uses a 128x128 color TFT screen, so the interface s even more crammed than the LSDJ's.

http://shiru.untergrund.net/temp1/ebt_ui.png

The software sound engine is vaguely connected to our 1-bit stuff: it is based on the wtbeep engine. It takes the best of it, and improves the sound quality using the device's power. It features four channels with a clean sound. It also features an actual volume and stereo left/center/right controls, so it is not really 1-bit anymore, but there are 4 volume levels only, and no volume envelopes, so it still sounds similar to the 1-bit stuff.

The tracker engine features single-channel patterns of variable lengths (you can mix up different lengths in an order position), and MOD-like effects with up to two effects per note.

The package includes the ESPboy binary, a Windows SDL build (should be easily portable to Linux and such, but not ready-to-use yet), the source code of course, and a detailed PDF instructions. Released under WTFPL.

No demo songs yet.

Download

Also, there is github, but it will be lagging behind I bit, I think.

29

(5 replies, posted in General Discussion)

Furnace tracker it is. It supports a gazillion of platforms. Not sure how did they get the low notes, tho, can't find a low level export there. Perhaps it is in-tracker only at the moment.

30

(3 replies, posted in Sinclair)

I think (not really sure) I've seen an editor that has been used to make this demo, but I can't recall where it potentially could've get it. Perhaps it was on a forum back in the day.

Edit: oh yeah, it is actually mentioned in the comments. The link is dead, but archive.org saves the day: https://zx-pk.ru/threads/5577-redaktor- … uzyki.html

31

(164 replies, posted in Sinclair)

Confirmed, the script got broken a bit during the recent updates. Re-uploaded the archive with a fixed one.

As we're focusing on actual old platforms that only has one bit to flip, and not many trying to do VSTs, I think, no one tried to do min/max. Although I believe it will sound exactly the same, just having an unwanted DC offset that will result in a pop at beginning and end of a track.

33

(4 replies, posted in Sinclair)

Not really related, but a nice visualization of what is going on for each of the channels: https://www.youtube.com/watch?v=F1e2MOeo5eU

I think we should try to extract at least the sound loop code somehow, and replace everything else with the traditional pattern structure. This way we'll get the iconic sound at least, even though with a high memory consumption.

34

(164 replies, posted in Sinclair)

it certainly should be possible at cost of some sound quality. IM2 is used there to avoid having a loop counter inside the sample loop, because the whole thing is very heavy on register use. The counter instead located inside IM2 handler and it breaks the sample loop once it played enough frames.

35

(164 replies, posted in Sinclair)

Yeah, it has quite a non-trivial exit routine, overlooked some things. Fixed, re-download the main archive.

36

(164 replies, posted in Sinclair)

Another update. In order to cover more of the digital/sample-based Spectrum engines I'm doing some changes in the sound backend. I encapsulated Game_Music_Emu into an intermediate library called PlayLayer. At the moment it only uses GME, but the GME has been modified by me, so it is forked from the main version. Now there is Covox, Stereo Covox, and SounDrive support in GME's AY emulator, so you can use these devices in Sample Tracker engine now.

PlayLayer's purpose is to simplify adding other container formats without adding them into GME. I can just add any emu/player I want into this library, and it'll decide whatever should be used to play a data chunk. The intent behind it is that in order to support 128K+ sample-based engines I need to use a container other than AY, and a regular emulator Z80/SNA snapshot seems to be a reasonable choice, so this may be added eventually, without integrating it inside GME (which would be a major headache).

37

(164 replies, posted in Sinclair)

Fixed it, replace this file in the /engines/ directory.

38

(164 replies, posted in Sinclair)

Yeah, it is a bug. Actually I didn't test TAP/SCL exports, and I forgot they (the BASIC part) were hard-coded for #8000 blocks.

Will fix it soon. It is just not very easy to generate BASIC code from a program, it has quite a complicated structure.

For now you can MERGE the loader and replace the 32768 to 25088, it'll work.

39

(164 replies, posted in Sinclair)

Also, extracted a bunch of samples from various TR-DOS disks. They were borrowed from PC software of the time, but they may come handy to re-create the sound of the old digi songs: http://shiru.untergrund.net/temp1/raw_p … om_90s.zip

40

(164 replies, posted in Sinclair)

Another update. Finally, a sample based AY engine! Reverse-engineered the code from Sample Tracker 2.1, and as it works with 48K, it was possible to fit it into the *.AY file container (although I've got ideas on how to go 128K and beyond).

I had to modify Game_Music_Emu in order to make it work, as it didn't fully support simplified AY ports decoding.

The engine also supports Covox, Stereo Covox, and SounDrive, I kept it in Z80 code, but GME does not support these devices, and it seemed to be kinda difficult to add them in, so for now these are not audible in the tracker, but still can be exported as code. This may change in the future.

The engine is already bundled with the tracker. Here is the original ST2.1 reversed code without much modifications, just in case anyone wants to look at it.

41

(3 replies, posted in Sinclair)

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.

42

(164 replies, posted in Sinclair)

A minor update to v0.45. I honestly don't remember all the fixes I did, mostly minor improvements to the engine scripts here and there.

43

(4 replies, posted in Sinclair)

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.

44

(10 replies, posted in Sinclair)

I guess so. Thanks for report!

45

(10 replies, posted in Sinclair)

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).

I don't know. I have many reports regarding FL-related issues, but I'm not an FL user, and it works just fine in the FL demo version on my end.

I mean, it is very likely there is some problem in my UI code, but VST format is extremely badly documented, and almost no one programming UIs directly as I did, most VSTs created with SynthEdit-alike constructors. So I can't even know for sure.

47

(10 replies, posted in Sinclair)

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

Meanwhile, fixed the 128K problem.

48

(4 replies, posted in Sinclair)

Released a few days back it seems, some source dumps off the Follin's Tatung Einstein floppies. Contains some Z80 and 6502 stuff, not sure which exactly. No comments spotted in the files.

https://github.com/breakintoprogram/archive-follin

49

(4 replies, posted in General Discussion)

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.

50

(4 replies, posted in General Discussion)

Why the output is 22050 Hz, tho? It will take an extremely good resampler/filter in the emu to make basic engines with channels interleaving (such as Music Box) to sound good at this rate, because the carrier tone will get well into the audible range otherwise.