Re: bintracker 0.1.1

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.

Re: bintracker 0.1.1

it works from another computer, so I guess it's the other one which has a limitation or a problem but I don't know what it could be. Your fix did the job for the numbers, sorry for the fuss.


Re: bintracker 0.1.1

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.

Re: bintracker 0.1.1

yes, numbers are working ok in the pattern data, only when editing names there is this freeze. But this computer has some strange behaviors, it's also on this one I have massive slowdown when using 1tracker. It's one of my most powerful computer (core i5, 8 Gb ram), I just think I need to install a new system from scratch on it.

30 (edited by utz 2017-09-19 14:39:20)

Re: bintracker 0.1.1

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


Re: bintracker 0.1.1

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

Re: bintracker 0.1.1

the arrown dropdown list is a great addition, thanks.

For the makefile, if you change clang++ to g++, there is still an error with LDFLAGS, because we must remove -stdlib=libc++ as well (maybe it has been changed in g++ > 5). I don't know if there is a clean way of switching to clang++ to g++, I've tried something like

ifeq "$(CC)" "clang++"
    LDFLAGS        = -stdlib=libc++ -L/usr/lib -lallegro -lallegro_image -lallegro_font -lallegro_primitives -lallegro_dialog -lallegro_audio
   LDFLAGS        = -L/usr/lib -lallegro -lallegro_image -lallegro_font -lallegro_primitives -lallegro_dialog -lallegro_audio

but it doesn't work like that.

I've made a pull request for the audioBuffer thing. What is the difference between the original code and your fix to make it compile on g++ 4.8? If you think it might be a problem, just don't integrate the pull request. https://github.com/utz82/bintracker/pull/4/files


Re: bintracker 0.1.1

Your changes don't seem to break anything, so I've pulled them in. Thanks! smile 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).


Re: bintracker 0.1.1

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.

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.

Re: bintracker 0.1.1

I see. It's more complicated then. Do as you can wink
I like the idea to keep any pattern which is not eventually used (yet) in a song, but if it's impossible don't bother with this. Maybe a reminder: "beware, pattern_bridge01 and pattern_wip02 are not used in the song, they won't be saved" could help users not to loose anything?

Maybe it's possible to to have only numbers for naming a pattern (patterns:01, patterns:02) and then use an optionnal label to give a more friendly name, like this:

 blabla (not labelled)



Re: bintracker 0.1.1

I think the "don't save" option is pretty bad, so I definately want to solve it for MDAL2 wink 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:

   NAME="my super catchy intro"

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

Re: bintracker 0.1.1

ok, good idea for the NAME command.


Re: bintracker 0.1.1

garvalf wrote:

I have also an other bug, even from the beginning, sometimes the screen is mixed up when I start bintracker:


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 wink Could you run

glxinfo | grep OpenGL

on the machine that has this problem, and post the output?

39 (edited by garvalf 2017-10-08 08:31:55)

Re: bintracker 0.1.1

I have this on my home computer (the powerful one which has the pattern renaming problem):

 OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 660/PCIe/SSE2
OpenGL core profile version string: 4.2.0 NVIDIA 304.134
OpenGL core profile shading language version string: 4.20 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.2.0 NVIDIA 304.134
OpenGL shading language version string: 4.20 NVIDIA via Cg compiler
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:

I'll run it on my other computers as well.


Re: bintracker 0.1.1

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.

Re: bintracker 0.1.1

oh, this one is different from my screenshot problem. The flickering problem is on my computer at work. I'll test it tomorrow and try your fix.

42 (edited by garvalf 2017-10-10 10:18:57)

Re: bintracker 0.1.1

I've written a report on github. Still the same. It's an ATI video card.

Edit => your fix did it, thanks!