Hi Tom,

Sorting you out with some existing music tracks that are free to use with attribution wouldn't be too difficult I guess. It's the "not too much work to convert" part that has me slightly worried.

Do you have any experience with Python or Rust? If so, you could build yourself an XM converter using either Shiru's Python-based xmlib or my slightly wonky Rust-based xmkit. Once you have that, you might even be able to convince someone on here to write some music for you.

The in-game music you have now doesn't sound like 1-bit music though? Note this forum is about 1-bit music, not 1-channel music. Though Shiru has some music that's both 1-bit and 1-channel - but that wouldn't necessary be that easy to convert.

152

(164 replies, posted in Sinclair)

Having trouble with the Ear Shaver EX engine.

- When entering data at the loop start position, I get the good old "Engine not provided any data" error, with the addition of

Z80Ass error: label already defined!
Z80Ass error: label already defined!
 706: .loop
 706: .loop

printed to the console, and a single copy of this printed in the GUI.
- Sample import does not work, drums do not play any sound.
- Tempo seems completely messed up, I need values of at least 40 tpr to get any meaningful row length. Also, the drums seem to affect this - rows play a different length depending on the drum. The global tempo setting on the other hand seems to have no effect whatsoever.
- The new mml-style envelope editor is unusable with a qwertz keyboard, since | and * are not recognized (reading your last post on MuzCell I think you found a solution to this already, but thought I'd mention it anyway)

153

(2 replies, posted in Sinclair)

Well, I certainly won't complain about that set big_smile Couple of really obscure ones, too. Despite all the digging I did back in the day I somehow never came across that Jan Deak track, for example.

154

(164 replies, posted in Sinclair)

Huh, I never realized that 1tracker was actually released around the 30th anniversary of the Spectrum. Anyway, congratulations on 10 years of what I still consider to be the best tracker in the world.

Regarding whether to switch to an external assembler, I'd say it ultimately doesn't solve the problem at hand. Yes, it'll get you support for a range of platforms without too much trouble, but eventually you'll discover some other obscure platform you'd want to support (Sharp PC cough cough) and find that wla-dx or whatever you chose doesn't suppport it, so you're back to point 0. Secondly, if you're going to link in wla-dx, then 1tracker can't be WTFPL anymore. And that would be sad. Anyway I think it's better to invest time into building a custom extensible multi-target assembler. I believe it's a manageable amount of work.

Regarding pattern-less vs traditional, I'd argue that the pattern-based approach represents a local maximum - it's good, but it's ultimately sub-optimal. Therefore it makes sense to continue innovating with a pattern-less approach in 1tracker. I think showing that a different approach to tracking is viable is actually one of the project's main achievements. That said, I believe it's possible to implement a pattern-less abstraction on top of a pattern-based implementation, if you ever want to go down that route. Probably not worth the effort, though.

That sounds indeed like a very interesting beast. Quite capable but at the same time distinctly lo-fi. Consider me hyped for this journey of yours.

Thanks, great to see the beeper love continue down under. Also, looks like you're living in a really nice place.

I think I can support the Vtech machines fairly easily in bintracker, btw. Not sure when I'll get around to it though.

157

(135 replies, posted in Sinclair)

Next iteration. Up to 24.3 KHz sample rate, don't think I can go much faster.
And yes, this is completely pointless...

At this rate you'll have polyphony figured out before us, hehe.

It seems you missed the attachment. The system is a bit stupid, you have to first select the file with the Browse button but then also hit the Add File button.

159

(135 replies, posted in Sinclair)

trollolol

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

163

(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?

165

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

167

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

168

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

169

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

170

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

171

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

172

(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?

173

(1 replies, posted in General Discussion)

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

174

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