You are not logged in. Please login or register.
The 1-Bit Forum → Posts by utz
Ha, totally forgot to reply to this. I've actually experienced this kind of road before, think it was in Norway. Imo the result is not that impressive... but yeah, I guess it's mostly about the spaces between the gaps, so it's a kind of pulse frequency modulation 
So indeed, some 1-bit trickery could work.
In it's most basic form, this technique is actually getting quite common nowadays on highways, to alert drivers when they are going over the side line.
Not sure I understand the question, but have you filled all 4 positions on the current row of the sequence? If you have gaps in the sequence, like this:
00 01 -- --
02 -- -- --there will be random notes and effects.
More progress on this. Seperated the code that generates the attack transient, so it's now possible to use arbitrary source material. Attached example uses 50:50 square. 2 channels @ 7812.5 Hz. Some parasite noise remains, I'm afraid it'll be difficult to reduce it further.
Yes, that's the idea - except it's not a sample, it's generated in realtime!
Anyway, getting closer to a two-channel implementation. Still need to get rid of some 20 t's of overhead, though.
Ultimately it'd be great to come up with a more efficient way of implementing this, because even just some simple additonal modifications of the delay line can go a long way with this algorithm. Also, using a non-random source (for example a square wave) can produce some great result as well, but again takes too much time with my current implementation.
Edit: Probably the way to go forward is to render at a lower rate. Did some tests with rendering at 7812.5 Hz, it sounds not too bad (and will give more flexibility I hope) - see test2.tap.
Awesome! I think I'll be needing one of those as well...
What's the tune from 0:30 onwards, don't recall hearing that before?
After seeing this, I was curious if this type of physical modelling could be made to work on beeper.
Well... I guess it can. Voilà, a real-time synthesized string instrument on beeper 
This is only a single channel implementation, but there are 79 cycles wasted, so hopefully 2 channels of this will be doable. Another problem is that right now this works only with 8-bit dividers. It would theoretically be possible to go up to 9 or 10 bits, but this would cost a lot of cycles.
Thanks! No need to run it on your other machines actually, it was just to rule out that there's an OpenGL-related problem at hand with this issue.
I have also an other bug, even from the beginning, sometimes the screen is mixed up when I start bintracker:
https://lut.im/LF2ZDHrHSL/9S53pJWapik75sD7.png
when I pass the mouse over a mixed up icon, it displays just below the menu, it's just shifted. It happens at random.
Need your help again Could you run
glxinfo | grep OpenGLon the machine that has this problem, and post the output?
I think the "don't save" option is pretty bad, so I definately want to solve it for MDAL2 Should be doable considering the whole thing is gonna be rewritten from scratch anyway.
Regarding "labelled" blocks, I have to see about it. I like your idea, but on the other hand I want to avoid "special" cases as much as possible, to keep the parser fast and light-weight. So from a technical point of view, it would be better to do this:
PATTERNS:02
NAME="my super catchy intro"
blablablawhere NAME is a block constant, that is a command that can only be set once per block, and doesn't count towards the block length. Theoretically those exist even in the current MDAL standard, but aren't handled by libmdal. Which is another blocking issue towards adding support for various engines...
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.
I realize now that this is a much more significant problem than I thought. The problem is this: When you save a song in bintracker, it will iterate over the existing blocks (patterns/tables/etc) and save all of them to the file, whether they are used or not. However, when you load that file back into bintracker, MDAL does the parsing, and MDAL determines the block type from the usage context, which means for blocks that aren't referenced either in the sequence or by a command, the block type cannot be determined. So consequently those non-referenced blocks will be ignored, and will be lost the next time you save your song.
This is something that needs to be addressed in the upcoming new MDAL version 2 standard, but I haven't found a good solution to the problem yet. Actually in MDAL2 things will be worse, since there will be a new abstraction layer between user input and data output. Eg. right now, an input block is directly converted into an output block, but in MDAL2 this will be different. There will be abstract "input blocks" which are then converted into "output blocks" in multiple ways. Take for example PhaseSqueek: Right now, writing FxTables is very inconvenient, because the entire set of commands is affected. With the new abstraction layer, you will be able to write seperate tables for each channel or maybe even each command, and MDAL will take care of merging them into the actual FxTable blocks. tl;dr, we'll see a lot more different blocktypes in MDAL2.
So, as I said, I'm still looking for a solution for this problem, and I'd very much appreciate some input on this issue. Right now I'm leaning towards
requiring MDAL block names to be prefixed with the input blocktype name, eg. instead of ":pattern1", you'd write something like "PATTERNS:pattern1". Probably even go further and ditch pattern names (can you imagine writing a sequence for ZX-16 using pattern names?), so the new syntax would be something like "PATTERNS:01". (Actual pattern names would be implemented as a command, in this case.) However, this could get rather messy and unintuitive for users, considering that there might be a large number of input block types, and implementations will vary quite a bit depending on the engine. Eg. in ZX-16, there should be one single input blocktype (called eg. PATTERNS, containing one NOTE command and one SLIDE command), which can be used for each of the 16 channels. In engines with channels that have different capabilities (think Phaser1 for example), there could be different input blocktypes for each channel. So then we'd have "PATTERNS_CH1:xx", "PATTERNS_CH2:xx", and so forth - not exactly user-friendly imo. On the other hand, it'd be easier to avoid namespace clashes that way, which is actually a thing in MDAL1: It's perfectly legal to give the same name to a pattern and an non-pattern block, and theoretically the parser should magically figure out which is which, which doesn't happen of course.
Another solution would be to generate a list of unused blocks for each blocktype when saving a module. However, as mentioned before, I believe named patterns should probably go, because there are several problems with them.
Your changes don't seem to break anything, so I've pulled them in. Thanks! 
The main difference is that .swap() is faster, but I don't think it'll be that significant.
Regarding the makefile, stdlib=libc++ is a clang-specifc flag (linking against clang's stdlib rather than the GCC one). Things should work with g++ if you remove the flag from both LDFLAGS and CXXFLAGS. That said, I build with code::blocks myself, so the makefile probably doesn't get the love it deserves. Sorry about that... ultimately I should probably start using autotools or CMake to sniff the environment. It might become necessary anyway when I re-implement WAV export, which will require pulling in another library (most likely SRC/libsamplerate).
Version 0.1.1 is ready, btw. Mostly bugfixes in this one. Also the aforementioned alternate method of selecting items from dropdown lists, and a feature to randomize a selection of a pattern/table (mostly useless I guess, but I needed an RNG in the tracker so why not use it for this as well).
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
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
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.
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!
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.
It should be "audioBuffer", with a camelcase
Impossibru! Ok, I'll think about something new tomorrow. Thanks for your help, in any case
Whoops... I mean input.cpp 
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?
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!
Waaah, so many things Ok, I'll go through them one by one.
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 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?
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...
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.
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
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.
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.
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.
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.
The 1-Bit Forum → Posts by utz
Powered by PunBB, supported by Informer Technologies, Inc.