(25 replies, posted in Atari)

From what I remember SV isn't super strict with these deadlines. They are more there to motivate people to send stuff earlier than last minute, but I don't think they actually refuse entries that arrive later. I've definitely send stuff past the deadline before.

Haha, I was watching the demo (the live yt version, hoping a proper recording will appear soon) and thinking: "Hmm, this music sounds really Shiru-like. But it can't be. I wonder who did it.". And then the credits rolled... Turned out great, really good interplay with the visuals.

I don't quite understand about the MOD end part. Wouldn't the best approach be to take the whole song and have the converter chop it up to create an optimal set of sample data? Or was there no time to build an "intelligent" converter for this?


(25 replies, posted in Atari)

Thanks for the info! I'll try to make a Squat tune for the GTIA compo but I can't guarantee anything.


(5 replies, posted in Sinclair)

I finally got around to listening to it, dammit. Fantastic little release! Serenity sounds like it could have been an intro for Space Beeps yikes Love the arps galore on Mech Dance.

thwill wrote:

doesn't explicitly have any concept of a "rest", though that would be easy enough to add

Rest is an extremely useful feature, definitely worth adding.

thwill wrote:
utz wrote:

If so, you could build yourself an XM converter using either Shiru's Python-based xmlib or my slightly wonky Rust-based xmkit.

I obviously need to do some reading, and will try to do so before I post again. My initial thought is "Convert them into what ?", or is convert a euphamism for "play XM files" here ?

The converter should take an XM file as input and produce the required data statements for your music player. For 1-bit players, we usually use specially crafted XM templates that attempt to give a rough approximation of the final (converted) result, but in your case I think just some generic XM file with a single sine-wave instrument would be fine.

See this 1-bit engine package for an example of such a converter. Feel free to nick the xmkit library - it's pretty bad code, but it's C++.

thwill wrote:
utz wrote:

... you might even be able to convince someone on here to write some music for you.

For my little game that does not seem like a worthwhile use of somebody's time and talent.

The problem is that I'm not sure any of us have any ready made music laying around that fits the constraints of your player. You could, of course, grab some random XM file and convert that, but you'll find that more often than not musicians pack multiple elements of the music in the same channel, so taking a single channel and converting that to your player wouldn't make all that much sense.

A reasonably low-effort solution could be to find a MIDI of, say, the Tron movie theme, import it in an XM editor, edit it a bit to squeeze the main melody into one channel, and finally convert that to data statements for your player.


(2 replies, posted in Sinclair)

Yeah, saw it too, pretty funny. The audio quality is not very good imo but it packs quite a large chunk of wave data. So the compression scheme might be interesting.

cborn wrote:

Warning! The following errors must be corrected before your message can be posted:

    At least 60 seconds have to pass between posts. Please wait a while and try posting again.


lol jij typt te snel

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.


(121 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)


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


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


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


(113 replies, posted in Sinclair)


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


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


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


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


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


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