(1 replies, posted in Sinclair)

Wow, appearantly it's been almost a year since I published a new beeper engine. So it was about time for some good ol' t-state squeezing.

StringKS is an experimental engine that implements Karplus-Strong inspired string synthesis. It's more a proof-of-concept than an actually useful engine (hence no converter is provided), however it does prove that physical modelling is possible in 1-bit, and I think it's worth exploring this concept further.

Synthesis is done by creating an initial ring buffer from various sources (at the moment, ROM noise, rectangle wave with variable duty, and saw wave are supported), and then continually running a simple low-pass filter over the buffer. The size of the buffer determines the pitch. It is also possible to source from user-created data (so theoretically one can start from a pre-filtered buffer to create softer attack transients). Additionally, I threw in PWM sample playback on one of the channels, and regular rectangle wave playback (also on one channel only). There's also a (rather brutal) overdrive mode. All synth methods except the saw wave one support a somewhat crude 3-bit volume control.

source code
An extremely uninspired demo tune is attached.

- 8-bit frequency counters only, so the available note range is rather limited.
- At higher notes, tones will fade out very quickly.

I believe it's possible to rectify these issues, but more research is needed. One possible approach I experimented with was to generate data on the fly with the usual add-and-compare method while keeping track of the low-pass cutoff. It works but so far sound quality is worse than with the buffered approach. Another way might be to pre-scale the speed of buffer iteration to reach lower frequencies (e.g. update buffer pointer only every other sound loop iteration), and to slow down decay by only running the filter on every other buffer iteration. Still need to find some free t-states for that, though. Perhaps splitting updates so only one channel gets updated per sound loop iteration might be doable. Well, I'm open to ideas, of course wink

Thumbs up wink
A small note about Huby, using Beepola/1tracker is strictly optional for transcriptions. You can also generate music data directly from the imported MIDI data in OpenMPT by using the Huby XM converter. However, the best option is always to ask a chiptune musician to do a cover for you, rather than converting from MIDI data wink

Thx wink Yes, sound and video examples were not recorded for copyright reasons, but you can find all the examples over at the 1-bit timeline post (which I've been updating quite a bit lately).


(1 replies, posted in Sinclair)

Ha, neat!

I think anteater has some flaws (namely incorrect tuning due to insufficient frequency divider size). On the other hand, looking back it was probably not that bad for a first (well, probably second or third) attempt big_smile

As much as I'd advocate trying some of the newer beeper engines, the most convenient for you would be to use Tritone, as it's natively supported in z88dk.

Also, don't worry too much about size. Once you use compression (and only unpack into a buffer when you need it), data size doesn't really matter that much. I think z88dk has zx7 compressor build in, which works fairly well on music data.

I don't know what would be the equivalent in SDCC syntax, might be as simple as

oldSP = $+1

Generally, what this pseudo-op construct means is: "assign a label (oldSP) to the current address ($) + 1". So in this example, oldSP will point to the address immediately after the "ld sp,nnnn" instruction, which happens to be the "nnnn" part. There is some other part in the code (usually in the init part) that writes the value of SP at that point in time to the location of oldSP. The snippet "ld sp,old_value" is then usually called on exit, to restore SP to it's proper value, as many beeper engines mess with the stack a lot.

Anyway, the point is that if you don't have any form of "label equ $+x" available, you can also simply locate all points in the code that write to 'label' (in case of the SP backup there'll usually just be one such location). That write op will look something like

  ld (oldSP),sp

which you can change to

  ld (oldSP + 1),sp

and then change the "oldSP equ $+1" to simply "oldSP".

Did a talk about music on mainframes 1949-1965 at the Vintage Computing Festival Berlin last weekend. Nothing new if you've been keeping an eye on the 1-bit timeline post, but anyway, here you go:

https://media.ccc.de/v/vcfb18_-_90_-_en … ames_-_utz

Your music_data should simply contain the pattern pointers, the extra "patterndata" structure is not needed. So

   defw pattern1
   defw pattern2
   defw 0

The 0-word at the end of the music_data block marks the end of that block, in the same way that the 0-byte at the end of a pattern marks the pattern end.

However, I don't know if Ear Shaver supports this kind of sequence/pattern structure out of the box, perhaps some adjustments to the data loader are needed.

Yep, use synth drums instead of the digi ones, and you should be fine.
Also, song data generally compresses well with zx7, apack, exomizer etc.


(8 replies, posted in General Discussion)

Hmm, would you by any chance be interested in contributing to libmdal? I haven't defined any API for dealing with MDAL modules yet, but in general what I'm looking for is a set of utility functions for algorithmic pattern data generation that users can glue together to form actual generators. Perhaps later wave data as well, but it's not a priority right now. New lib is written in Scheme (specifically Chicken Scheme).


(8 replies, posted in General Discussion)

Slightly related question, did you ever play around with the Nyquist prompt in Audacity to generate/manipulate wave data?


(8 replies, posted in General Discussion)

Hmm algorithmic pattern/sample generator, how does that work? Does it write to XM, or directly to .asm? What are the inputs to the algo? I'm asking because I eventually want to support algorithmic data generation natively in the upcoming new libmdal/bintracker, but I'm not not really much into that field myself.

Anyway, nice release wink Hopefully I'll get around to making something for the label one day but first I gotta finish that thing I promised for Bit Rot ages ago... ducks

Well, so the duty thing would be pretty much like in modern pulse-interleaving engines.

I assume there must be a connection between this and the Cybernoid series. Netherworld, too, and Turbo Boat Simulator.
https://spectrumcomputing.co.uk/index.p … mp;id=5456
I'm assuming Dave Rogers wrote the beeper music for all of these (Nick Jones always used Wham for beeper). I think the engine must be his as well, because Turbo Boat Simulator is not a Hewson Title and none of the other usual suspects were involved in this. Also I wonder if it's always the same engine or if there's some evolution from Cybernoid -> Cybernoid II -> Netherworld/Stormlord.

Edit: Wow, forgot how insane that Netherworld music was. Easily one of the top monophonic beeper titles.

Sadly it seems Dave Rogers didn't have much love for the beeper, actually:

4: How was it working with the single channel Spectrum Beeper?

What can I say? Incredibly limiting would be an understatement. I always did the best I could with the 128k sound, trying to overcome it's limitations, but the beeper just felt like a waste of effort. The only time I did anything specifically for the beeper was for Cybernoid - a three channel tune for the 128k and a completely different one for the 48k.

The rest of the time I took the lazy way out and just squashed the three channel AY-chip data down into one channel for the beeper.

http://zxspectrumgames.blogspot.com/201 … rview.html


(6 replies, posted in Sinclair)

He doesn't have any for offer, but there's a good chance he'd build you one on request. https://www.bytedelight.com/?page_id=499
I've bought stuff from the guy before and can vouch for the quality of his products.


(6 replies, posted in Sinclair)

Ha, just read your comment on yt about playing the lead with a laserharp. Well, a ZX laserharp does exist!
Just need some beeper software for it yikes


(3 replies, posted in Sinclair)

Thanks guys wink Yes, the last song is indeed the one I played at IVP last year. To be released on my next album, coming out in 2125 yikes


(3 replies, posted in Sinclair)

A recording of my live set at Ohrbit Festival 2018, featuring the usual beeper metal, calculator unce, and senseless screaming.


(33 replies, posted in Other Platforms)

Ha ha epic demo, mate! https://www.youtube.com/watch?v=3db3HIQuGds


(6 replies, posted in Sinclair)

Fantastic work, mate. Very professionally executed, and the music's great. Keep 'em coming!


(33 replies, posted in Other Platforms)

Hmm, very intriguing. So there was some Ukrainian involvement.
More info: http://nodehist.fidonet.org.ua/?address=2%3A461%2F256 http://nodehist.fidonet.org.ua/?address=2%3A461%2F60


(33 replies, posted in Other Platforms)

Thanks for your hard work, Shiru. Any chance of migrating from VCL to CLX though, so the emu could become portable?


(3 replies, posted in Sinclair)

Thanks, detective, much obliged! wink
We had another thread about this stuff: http://randomflux.info/1bit/viewtopic.php?id=153
Sadly punBB doesn't allow to merge topics (only with some 3rd party mod which reportedly doesn't work properly), so I'll have to think about collecting all this info into a sticky master post at some point.

Interesting, always nice to see experiments like this happen.
I don't quite understand what's the difference between this and regular DPCM, though.

You can just load .sna from divMMC. Otherwise there's SnapToTap for .sna->.tap conversion, and z802tzx for .z80->.tzx conversion (which you'll then have to convert to .tap for use with divMMC). See http://www.worldofspectrum.org/utilities.html#tzxtools
Assuming that the programs are written in pure BASIC, you could probably also dump the BASIC from Fuse and then shove it through zmakebas.

Hm, seems these are rather simple tools. But somewhat reasonably priced so still a nice item to have. Looking forward to your User Experience Report big_smile