Contacted Lyndon Sharp about this, and he's confirmed that he wrote that engine (and he most likely did the music conversion as well), based on WHAM. According to him, Codemasters wanted to avoid using WHAM because of license issues, so he sent them this one. It was only used once, as Codemasters still thought it too similar. So eventually Lyndon transformed it into what we now know as the LSengine'89.

Now waaaaait a minute. I see (hear) your point regarding the drums (and yes, it's a Codemasters title) - but there's no way this is LSengine, because the tones sound totally different. The characteristic whistle of the squares makes me almost certain that it's WHAM. So could it be that somebody hacked in the drums from LSengine into WHAM? Only one way to find out... Archive.org has a .z80, so let's take a look. Hmm, it's not the exact code from WHAM, but there are some pretty striking similarities... Exiting stuff, and well spotted introspec big_smile

478

(51 replies, posted in Sinclair)

If I had to set up a new system, I'd actually be tempted to give one of the *BSDs a try. It's getting increasingly difficult to keep Linux pulseaudio-free, and I don't trust this systemd stuff either...

Btw selecting from dropdown lists is now possible with arrow keys and enter wink

Hi Catmeows,

2) is indeed just monophonic arps.
3) is almost certainly Mark Alexander's driver (WHAM! The Music Box).
1) seems to be monophonic arps as well, but with a dedicated, pretty sophisticated driver. Not sure about this one, maybe others know more.

480

(51 replies, posted in Sinclair)

Ok, that's good to hear. So, seems I just gotta fix one more bug reported by Tufty before the 0.1.1 release.
Would be interesting to know why it fails on your other machine, though. I mean you can enter numbers in the actual pattern data, right? The pattern name editing thingy uses another keyhandler, but based on the same principle, so I'm really puzzled about what's going on here.

Great find, Tufty! I'm too stupid to play the game but... Walk like an Egyptionnnnnnn! big_smile

482

(51 replies, posted in Sinclair)

That's most likely a bug in liballegro, iirc they already acknowledged it on their bugtracker. I'll see though if I can do something to mitigate it.
Regarding the pattern renaming bug (should also affect the AUTHOR and TITLE commands on the General tab), I'm a bit at a loss right now. Well, we'll figure it out eventually... I might build the next release package without fixing it, though, if I can't find a fix tomorrow.

483

(51 replies, posted in Sinclair)

It should be "audioBuffer", with a camelcase wink

484

(51 replies, posted in Sinclair)

Impossibru! Ok, I'll think about something new tomorrow. Thanks for your help, in any case wink

485

(51 replies, posted in Sinclair)

Whoops... I mean input.cpp yikes

486

(51 replies, posted in Sinclair)

grrr damnit!
Ok, could you please add the following in line 992 of status.cpp

cout << al_keycode_to_name(keyEv.keyboard.keycode) << endl;

then run bintracker from console, try to enter some letters and numbers, and tell me the output?

487

(51 replies, posted in Sinclair)

I've implemented a fix for the "symbols instead of numbers" problem. If you have some time to test, please let me know if it works!

488

(51 replies, posted in Sinclair)

Waaah, so many things big_smile Ok, I'll go through them one by one.

garvalf wrote:

I've set the keyboard to FR. Now I have something odd. I won't open an issue because it's maybe a quick fix.

Alt+1...+5 is working fine for changing the octave. Alt+6 is decreasing the length of the song instead of choosing octave 6! Alt+8 is increasing the octave, as expected. Alt+7 does nothing. In english keyboard mode (I've changed my keyboard with setxkbmap us), it's similar, except that alt+6 is working as expected.

Hmm, that's not good. Unfortunately it's not a quick fix, because it looks quite correct in source yikes So I will have to investigate this.
Edit: Ok, found the problem. Now, how to fix it is another question.
Edit2: Alt+6 should be fixed now. Alt+7 I can't reproduce on xkbmap US, is it still broken for you?

garvalf wrote:

For the deletion of some notes, I found it strange that "del" is shifting all values in the column up. Probably some trackers are doing this as well, but I think it's more commun to just delete the value with "del", and shift values up with "backspace" (like in 1tracker or milkytracker). But we can get used to it.

Good point, I'll consider it. There was some reason why I didn't do it like that, but the fact that I can't actually remember the reason means it was probably not a good enough reason in the first place...

garvalf wrote:

Also the problem is sometimes the keyboard responds odd and I get two inputs instead of one. So instead of deleting 1 note I wanted to remove, and stay on the same place, it will delete the note and the next one not supposed to be removed.

Jangler commited some code yesterday which should, in theory, fix this issue. Though it's quite likely the bug is still there. Let me know if this keeps popping up.

garvalf wrote:

For the selection of special commands, I didn't understand how to select the value until I read the manual. Well maybe I'm a bit dumb, but when I began to type, I got a selection list. I tried to select one item with the arrows, but it didn't work. I tried to click, it didn't work. I tried to type the first letter of the command, hoping it would cycle through all the item (on/off), didn't work either. Then I discovered we have to enter the first letters. It's that simple. But maybe using arrows or cycling with only one letter would make it simple for newcomers, just an idea (maybe using mouse it too overkill). After, I noticed for some commands, like up/down, just typing the first letter works so it's good when you're used to the tool smile

I agree, it's somewhat counter-intuitive at the moment. Arrow keys should be possible. Mouse support would be great, but very difficult to implement. Still, it should happen at some point.

garvalf wrote:

well, I have a new problem, and a new bug...

With the sequence list:

first, I made a pattern. And I wanted to make a variation on it, so I "cloned" the first pattern. But my cloned pattern name (blk1) has just replaced my original pattern (pattern00) in the sequence list, and I can't find a way to select the first pattern (pattern00) which as just disappeared. The arrows around the pattern name are supposed to cycle though pattern already in sequence, so I can't get my pattern00 back. (I solved this easyly by editing the text file of course)

This works the same way as the "special" commands. Just type some letter and you'll get the drop-down list.

garvalf wrote:

The manual also says "Any patterns not used in the sequence will not be saved in your module file, and will be lost when you exit Bintracker or load another track.".

I find this very dangerous! Deflemask is doing the same and I've already lost some patterns because of this. Is there a reason you can't keep it in the mdal file? It wouldn't cost much space in the source file. I would find this more secure. Yet, when I've loaded my mdal file, all my cloned patterns, which are not used in the sequence, were still present in the file. So I don't understand this warning, maybe it's not implemented yet?

Hmm, so maybe I didn't implement it like that after all? *head scratch* That'd be great, actually! I'll check if this is really "safe", and adjust the manual accordingly.

garvalf wrote:

Now for the bug, with the FR keyboard, when I want to enter for example blk1, I type blk shift + 1, and instead I get blkampersand, same for eacute instead of 2 etc.

You mean it actually lets you enter a literal &? Dafuq... I mean you're not supposed to use shift for the numbers, but also bintracker should actually not let you enter invalid strings like that.

489

(51 replies, posted in Sinclair)

Wow. I mean 4.8 isn't exactly fresh, but one would expect that they'd be done implementing the C++11 standard at that point.
Ok, if it's just sound_emul.cpp:85 giving you trouble, you can replace that line with

audioBuffer.str("");

490

(51 replies, posted in Sinclair)

garvalf: That's very odd, can't wrap my head around it. I just pushed some changes though, could you try to 'git clone https://github.com/utz82/bintracker.git' and compile that again? Btw -no-pie is only needed on new GCC, to force it to produce actual executables.

Shiru: Ok, tried some things. Could you check if this version still creates a zombie on your machine: https://irrlichtproject.de/transfer/bin … .1.0.1.exe

491

(51 replies, posted in Sinclair)

That's an odd one. I assume that on your system, bintracker.exe fails to be registered as non-console app. Which Windows are you on? Does the error also occur when you start bintracker via console?

Edit: nevermind, I've been able to reproduce the issue. Though I have no clue how to fix it atm...

There's also an issue with the exit confirmation on unsaved changes, message box will show a single "OK" button instead of the 3 custom ones it should show. This is a problem with the gfx lib, working on a work-around atm.

492

(51 replies, posted in Sinclair)

So the time has come to drop this, I guess...

bintracker is here. It's a new beeper music editor (and in the future, possibly more than just beeper), inspired heavily by both 1tracker and Beepola. At this point, it supports betaphase, PhaserX, PhaseSqueek, and Pytha. Bintracker runs on Windows and Linux. It should be possible to build it on MacOS, but I haven't tested that.

DOWNLOAD (source + win32 .exe)

Bintracker runs libmdal as a backend, so in theory it can support any engine that is supported by MDAL. However, at the moment, bintracker only implements ZX Spectrum 48K support. Also, MDAL/libmdal is still in it's infancy, and will have to undergo some major changes before moving forward.

Bintracker is currently in a very early beta stage, so bugs will be a common occurance. Please report them here, or (preferably) hrough the github issue tracker.

Currently known issues:
- Sound emulation is not very accurate (in fact, emulator will have to be rewritten completely)
- Display may glitch after loading a tune or starting a new one (need help finding out why and when exactly this happens)
- Keyhandler may occasionally destabilize and register accidental keypresses (again, any help on this is appreciated)


Massive thanks go out to Shiru, who got me started by tossing around the idea of having "some sort of an MML compiler for beeper". Also, bintracker would never have been possible without the amazing 1tracker, which will, without a doubt, remain my favourite tracker.

Another big thanks goes to Chris Cowley for all the work he's done to almost single-handedly kicked beeper music into the 21st century with Beepola.

And of course, big thanks to all beeper fans, 1-bit musicians, and especially beeper engine authors!

Update 17/09/21 - v0.1.1 released

493

(7 replies, posted in Sinclair)

Sure, no prob about the instagram thingy. Hope to do some more works with this engine as well because it rocks!

Shiru, one feature request, would it be possible to automatically detect&cut silence at the end of samples for the 1tracker import?

494

(7 replies, posted in Sinclair)

Sorry, I'm keeping that under wraps till my new Spectrum album comes out (probably in Spring 2018 as things stand now). I'll send you the .tap, though, if you like wink

Holy moly, what a massive Frankenstein of a board! So finally it's all coming together, eh? Congratulations mate, this is a great achievement. And I guess it was quite some work despite you claiming to "just reuse code and parts from other projects" big_smile

496

(22 replies, posted in Sinclair)

That's a lovely tune, Garvalf!

497

(2 replies, posted in Sinclair)

Ok, here's one for the lulz.

nanobeep2 is a tiny sound engine for the ZX Spectrum beeper. Unlike the original
nanobeep, the design goal was not to make the player as small as possible, but
to cram in as much features as possible in less than 100 bytes. 

In it's most basic form, the player takes up 64 bytes of memory. A range of 
additional features can be activated via assembler switches, increasing the size
of the player up to a maximum of 99 bytes.

Core (minimal) player features:

- 2 square wave channels
- global 8-bit tempo resolution
- 8-bit note dividers (~4 octaves, lowest notes may be detuned)
- limited keyboard checking (checks only Space, A, L, Q)

Additional features:

- border masking
- full keyboard checking
- PWM sweep sound
- click drum
- per-pattern tempo setting
- increased note range (6 octaves)

No XM converter, it's just a proof-of-concept at the moment.

source
download

Lame 380 byte demo tune is attached.

498

(22 replies, posted in Sinclair)

If I'm not mistaken, it's basically a matter of resetting prm and Kp to their default values. Looks like it's 256 for prm, and 64 for Kp.
Seems like the doc is wrong, too - Kp should be in bit 8..13, obviously. My bad wink

499

(166 replies, posted in Sinclair)

In theory, what would be the options for play position tracking (aside from approximation via playtime, which is not viable I think)? Is there a possible to have GME do a callback at given breakpoints?

500

(37 replies, posted in Other Platforms)

Well, let's just say everybody has their own goals and methods, alright? For my part, I'm quite interested to hear about yours, chupo_cro (even though I'm personally more interested in coding AVR asm than C). Either way, probably best to continue this discussion in a new thread.

chupo_cro wrote:

Something that might be interesting - my song data format is not tracker-like (patterns of tones/commands) but is rather an array of tone[|CMD], duration[,command][, parameter] per channel (array of uint8_t) so it is quite easy to enter the song by looking at the musical scores and typing the data. Some commands can be specified just by OR-ing the tone with the command and some need to be specified by using CMD flag and the additional byte as command specifier and maybe one more byte as a parameter. The durations are specified as t1 (a whole note), t2 (a half note), t4 (a quarter note), t8, t16 or as the combination - for example t4+t8 is a quarter note with the dot.

Now, while I see your reasoning behind it, I think this approach has some drawbacks. The main issue is that you will find few people who are willing to write music for your engine in a text-based format. While music markup languages have some fans (even around here wink), the vast majority of users prefer trackers nowadays. And this kind of sheet-music oriented format does not lend itself well to a tracker implementation, since trackers don't care about note lengths. It might be worth considering to "inverse" the length format, so that t1 would be the smallest unit (ie. semi-quaver). This way, it'd be still relatively convenient for transcribing sheet music, while at the same time making tracker support a little easier. The other thing you have to worry about is row transition length. The more complex the data format, the more time you need to decode it - time that you can't spend on synthesis. It's normally not such a big issue with PFM-based synthesis, but once you get into pulse-interleaving/volume faking, you will notice a significant impact on the sound quality. Of course, with something like 10 channels, you have to start worrying about data size as well (so it would make sense to have patterns per channel instead of one pattern for all channels). But for 2 channels, I find split patterns aren't worth it in most cases.