Aye, that looks... pretty bad. I'm actually surprised to see such a result from a resistor ladder. But good to know, thanks a lot for investigating.
One question, looks like there are nine pulses, but I would expect 8, with the first one being silent. Do you know what's going on there?

In any case, I'm afraid I won't get around to this any time soon. And first we need to emulator to emulate sound correctly, anyway.

Yes, I would try reload-stuffing the sreg at the highest (or at least high enough) rate, too. The problem with that approach is however, that with an IRQ running at such high speed, you can't get much work done in the interrupt. So at best, this still blocks CPU most of the time.

Another approach would be to to set the max shift freq and just rotate patterns of %01010101/%00010001/%01110111/#ff in combination with playing with built-in volume. That way, you can update at a fairly low rate, say a couple thousand hertz. Though I'm not sure if it's possible to achieve frequencies outside the audible range in Lisa.

Edit: You know what might work, too? Treat the sreg as a 1-bit dpcm decoder. There's plenty of RAM so that could be fun.

No worries, I didn't do any work on Shiru's PET player, I just happened to work on some PET stuff at the same time.

Yes, we'll definitely need proper sound emulation. Either way I guess you've just signed yourself up for some beta testing if we get around to coding something big_smile

154

(164 replies, posted in Sinclair)

Disabling JIT didn't help, unfortunately. What's strange is that it spits out this line before segfaulting. Is there any way to get some debugging messages out of Angelscript? With those "engine did not provide any data" errors I tried to debug it in gdb but the whole Angelscript part is just one big blackbox.

Edit: Probably not helpful, but here you go anyway

#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x00007ffff78c0d28 in __vfprintf_internal (s=0x555556472f40, format=0x5555556a20a9 "%s (%d, %d) : %s : %s\n", ap=0x7ffffffdf1e8, mode_flags=0) at vfprintf-internal.c:1647
#2  0x000055555557901b in log_add (format=0x5555556a20a9 "%s (%d, %d) : %s : %s\n") at log.h:66
#3  0x00005555556918c6 in asCScriptEngine::WriteMessage (message=0x555556eea110 "Signed/Unsigned mismatch", type=asMSGTYPE_WARNING, col=10, row=542,
    section=0x555556ed9250 "/home/heinz/classic/sinclair/zxspectrum/beeper/1tracker-0.4/1tracker_src/engines/peskysoundzx.1te", this=0x555556d8fed0) at libs/angelscript/source/as_scriptengine.cpp:1229
#4  asCScriptEngine::WriteMessage (this=0x555556d8fed0, section=0x555556ed9250 "/home/heinz/classic/sinclair/zxspectrum/beeper/1tracker-0.4/1tracker_src/engines/peskysoundzx.1te", row=542, col=10, type=asMSGTYPE_WARNING,
    message=0x555556eea110 "Signed/Unsigned mismatch") at libs/angelscript/source/as_scriptengine.cpp:1207
#5  0x000055555561832e in asCCompiler::Warning (this=0x7fffffff08a0, msg=..., node=0x555556e34fd0) at libs/angelscript/source/as_compiler.cpp:5190
#6  0x00005555556449cb in asCCompiler::CompileComparisonOperator (this=0x7fffffff08a0, node=0x555556e34fd0, lctx=0x555556d6e090, rctx=0x555556e1dd10, ctx=0x555556d6d830, op=ttLessThan) at libs/angelscript/source/as_compiler.cpp:15006
#7  0x000055555562d5ff in asCCompiler::CompileOperator (this=0x7fffffff08a0, node=0x555556e34fd0, lctx=0x555556d6e090, rctx=0x555556e1dd10, ctx=0x555556d6d830, op=ttLessThan, leftToRight=true)
    at libs/angelscript/source/as_compiler.cpp:13925
#8  0x000055555562466b in asCCompiler::CompilePostFixExpression (this=0x7fffffff08a0, postfix=0x7ffffffef690, ctx=0x7ffffffefd30) at libs/angelscript/source/as_compiler.cpp:9051
#9  0x000055555562492e in asCCompiler::CompileExpression (this=0x7fffffff08a0, expr=<optimized out>, ctx=0x7ffffffefd30) at libs/angelscript/source/as_compiler.cpp:8981
#10 0x0000555555625822 in asCCompiler::CompileCondition (this=0x7fffffff08a0, expr=0x555556e34440, ctx=0x7ffffffefd30) at libs/angelscript/source/as_compiler.cpp:8967
#11 0x000055555564bc2a in asCCompiler::CompileIfStatement (this=0x7fffffff08a0, inode=0x555556e345d0, hasReturn=0x7ffffffeff9f, bc=0x7ffffffefeb0) at libs/angelscript/source/as_compiler.cpp:4349
#12 0x000055555564b011 in asCCompiler::CompileStatementBlock (this=0x7fffffff08a0, block=<optimized out>, ownVariableScope=<optimized out>, hasReturn=0x7ffffffeff9f, bc=0x7ffffffeffe0) at libs/angelscript/source/as_compiler.cpp:1158
#13 0x000055555564bd76 in asCCompiler::CompileIfStatement (this=0x7fffffff08a0, inode=0x555556e34e90, hasReturn=0x7fffffff0330, bc=0x7fffffff0240) at libs/angelscript/source/as_compiler.cpp:4395
#14 0x000055555564b011 in asCCompiler::CompileStatementBlock (this=0x7fffffff08a0, block=<optimized out>, ownVariableScope=<optimized out>, hasReturn=0x7fffffff0330, bc=0x7fffffff03e0) at libs/angelscript/source/as_compiler.cpp:1158
#15 0x000055555564be43 in asCCompiler::CompileIfStatement (this=0x7fffffff08a0, inode=0x555556e3a430, hasReturn=0x7fffffff069f, bc=0x7fffffff05d0) at libs/angelscript/source/as_compiler.cpp:4434

Thanks a lot for another fantastic installment in your "Understanding Computer Sound" series. The amount of work you put into these is mindblowing.
Also yes, you totally convinced me that I want to program aunt Lisa. I think both Shiru and me still have nightmares from working with PET and 6522, but in theory it's a pretty good setup. 68k @ 5MHz is a bit meh, but not too bad considering the other goodies. 3-bit volume control on top of that is excellent. In my head, that translates to 8 channels polyphony already, hehe. However, from the video it sounds like the upper end is somewhat compressed, ie. the increase in volume is not linear. Could you check that with your oscilloscope?

156

(164 replies, posted in Sinclair)

Holy moly, what a massive update! Thank you so much Shiru.
Just had a quick look. Improved envelope editor is great. I'm especially happy about the addition of fluidcore, that is a pretty powerful one.

The thing compiled clean out of the box, However, peskysoundzx engine causes a segfault for me on startup, had to disable it.

home/.../1tracker-0.4/1tracker_src/engines/peskysoundzx.1te (459, 1) : INFO : Compiling void Compile(uint, uint, uint, uint)
[1]    14346 segmentation fault  ./1tracker

Same here about lack of time, as I mentioned earlier. Also 100% amen to this:

Shiru wrote:

1-bit stuff is very appealing in this regard, because you have only so many sound possibilities within a particular engine, and it gets more about music than about fine tuning every single knob on a synth of 1000 knobs.

Exactly the reason that got me into 1-bit. Except now we're constantly shooting ourselves in the foot by making more and more powerful engines. But I enjoy that even more than making beeper music, actually.

Ha, that's great, have fun with it! Btw I got most of my 2.5mm cables from flea markets, since those are used by a bunch of old chinese crap phones and such. Alternatively you could try to mod to 3.5mm: https://github.com/utz82/HoustonTracker … mage2.jpeg

And yes, I should probably amend the manual to recommend Windows user go down the TI-Connect path at this point, since it's become more and more tricky to make TiLP work on Windows. The only problem is that TI-Connect does not work with TI-82+SilverLink.

158

(21 replies, posted in Sinclair)

I think just adding the aligned/unbalanced version should be enough, unless you think that the unaligned version sounds drastically better (in which case I have a version that brings it down to 182 cycles). Both versions should be +3 compatible.

159

(21 replies, posted in Sinclair)

Ok, give this version a spin and let me know what you think. Sound loop is 4t longer and outputs are not 8t-aligned, but to my ears it doesn't seem to matter much. Drum timing correction probably needs to be adjusted but I think it wasn't correct to begin with.

Interestingly enough 188t is pretty close to Tritone's 192t, which seems to be kind of a sweet spot, as imo Tritone still wins hands down when it comes to smoothness of sound.

Edit: Got it aligned at 192t. 72t for ch1/2, 48t for ch3 - not the best for unbalanced volumes but perhaps good enough to fake some delay/echo.

160

(21 replies, posted in Sinclair)

These are all great ideas, Shiru. Really, I should go back and revisit a lot of my engines. If only a day had 48 hours... It's also not like the old times, where I could sit down and code for 12-14 hours a day. Anyway... what I wanted to say was, if you want to have a go at this, by all means do, because I'm afraid I won't have time for it in the near future.

Shiru wrote:

- Maybe make unorthogonal channels. Two with selectable waveforms, and one either a simple square tone (good enough for bass), or variable duty cycle tone. Should probably speed up the sound loop a little bit and make hiss less audible.

wtbeep's loop is actually pretty tight already, just 184t. Perhaps it's actually too fast. Iirc channel 1 gets 56t and ch 2/3 get 64t, which might mean that their volume is too low to mask unwanted noises.

Come to think of it, at just 184t it should actually be possible to make this engine compatible with the +2A/+3. In the end we established it was a matter of masking bit 3, didn't we? Might also help to get rid of the hiss. Hmm I guess that could be a rather quick fix actually, if we don't care about 8t alignment.

161

(6 replies, posted in Sinclair)

EXcellent work, Multicore is great, even better that you managed to press it into a form that works inside a tracker. I only had a quick play with the engine but it seems a lot of fun. I do hope you'll continue to explore the whole Earth Shaker concept. One more channel, resp ES modulator perhaps? I think I tried that once and that brings you into byte beat territory pretty quickly. On the other hand I think this is a good time for me to go back to using a two-channel engine, haven't done in ages actually.

162

(135 replies, posted in Sinclair)

Those are some great ideas/findings. I very much agree that we can and should push 1-bit drums further.

Sample offset can actually be very useful for kick drums. By skipping the initial attack phase you can make a kick punch less, so that gives you a means of varying expression. Also, I once read somewhere that the first 20ms of the attack phase have a profound impact on how we perceive a timbre, so that's generally something to keep in mind for the future.

Volume control is great to have of course. With 4 levels you could actually start to think about doing PCM drums. One idea I had regarding this is to use some sort of 1-bit ADPCM, where the A part is that you can "wrap" the volume around, ie if you currently have volume 4 and the next bit read is 1, that translates to vol 0, and viice versa with current vol 0 and reading a 0-bit. That way you can preserve the high end of noise-heavy samples.

The pitch via slicing seems very interesting. I think that could be useful for other purposes as well. Will have to dig into esex' source code, hehe.

163

(5 replies, posted in Sinclair)

Great find! Yeah, phase control is definitely a very powerful tool in the 1-bit world. I still got this idea in my head to use phase inversion/offset to make a sample player. Wasn't too successful I tried the last time, though. There are two problems, first of all beeper is too noisy for low volumes, and secondly volume control via phase offset is non-linear, which makes it tricky to use in a controlled manner.

Btw, did you ever pursue this idea of yours further?

164

(1 replies, posted in General Discussion)

Regrettably, we aren't living in the most uplifting of times right now sad

165

(135 replies, posted in Sinclair)

Good find. I've used xor phasing on >1bit signals in a couple of engines, but it never occurred to me that the effect strength could be controlled in this way. Very cool.

Btw, shouldn't it be possible to implement ring modulation like this?

Heh, nice. Well, the video surely deserves more than the ~20 views it had yesterday.

From what limited testing I've done, it also looked like apack is the better general purpose compressor, but zx0 seems to have a slight edge over the former when compressing beeper music data. Surprised to see that zx5 performs so much better than zx0 for Freezing Point.

Thanks. Yeah some of the newer engines chew through RAM like crazy. I'm still surprised to hear that it was such a tight squeeze. Would you share some more details on how you pulled it off in the end?

I remember seeing that article before somewhere. Like the video, too, very detailed and thorough, just like the article. I'd have some small complaints about some of the more in-depth bits on code and such, but overall it's very solid.

That's a nice package indeed. Such kick-ass tracks all around. And this makes me realize once more what an absolute wiz you are when it comes to echoes. During DiHalt voting phase those are always a dead give-away, haha. Also, I think Geostorm might be my new all-time favourite of your tracks.

171

(164 replies, posted in Sinclair)

Excellent, thanks a lot. I'm also glad to report that this version compiles out-of-the-box on Linux.

172

(129 replies, posted in Sinclair)

Nah, no first place for me this time, that was to be expected. I only had one day to spend on this, so didn't polish things up as much as I could have. So, congratulations on your well-deserved win, Shiru. Excellent work. Especially beating we with my own engine hahaha.

It was a very strong battle overall. Really like BioMech as well, that middle section with the fast arps sounds so slick. Surprising entries from AER as well, glad to hear some beeper from him again.

What about using Padauk PMS150c? Might make for a circuitry small enough to fit into an actual gift card.

Excellent article, thanks. I have a hunch this lsfr trickery could also be useful for 1-bit engine code.

ATTiny would be an interesting hardware emulation backend to support in Bintracker, actually. So Bintracker could serve as an editor for greeting card melodies, haha. Perhaps that's overkill for something this simple though.

175

(129 replies, posted in Sinclair)

Next DiHalt is coming up! Jan 6th-8th, with beeper compo as usual.