Search options (Page 20 of 41)

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

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?

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

Hmm, that's not good. Unfortunately it's not a quick fix, because it looks quite correct in source 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?

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

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.

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.

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

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.

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.

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

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

That's a lovely tune, Garvalf!

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

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.

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 ), 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.

Agreed, it's probably easier to make a new one from scratch.

Hmm, shouldn't be that difficult to implement on any soundchip, easier than sample/MOD playback imo. I wonder why nobody has done it yet. Seems like Atari SoftSynth is indeed the only program like this on 8-bit machines, and it's from f*cking 1985. The only other one I know is AHX, and that was on Amiga of course. Also Dragon 32 and maybe Thomson TO had something like it on the 6-bit DAC, though far less advanced.

Cheers guys It's probably not the most useful engine, more a tech-demo, really. The vibrato technique is certainly not ideal, need to explore further. Well, it's a start, at least.