Search options (Page 19 of 40)

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.

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

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

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.

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

It should be "audioBuffer", with a camelcase

Whoops... I mean input.cpp

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!

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("");

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.

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?

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"