The Amiga Future 146 was released on the September 3rd.
Amiga Future Aktion: Probeheft für 1 Cent
Im Augenblick gibt es im Shop unter https://www.amigashop.org die Möglichkeit ein Probeheft der Amiga Future für 1 Cent (+ Versandkosten, inkl. MwSt.) zu bestellen.
Amiga Future Promotion: Sample issue for 1 cent
We have a special offer for all of you who’ve gotten a taste of it: Right now you can order an Amiga Future issue for 1 cent (plus shipping costs and included VAT) at https://www.amigashop.org.
Gamescom Digital: https://gamescom.amigafuture.de
The official specification of DBM module format has been updated to version 1.3 with clarification of panning envelope points storage. The same document in Amiga Guide format will be distributed with the next beta version.
I need some clarification on the format, as some parts are rather ambiguous or are treated differently by existing loaders.
First, regarding the instrument panning, is it supposed to be an int16? MilkyTracker and OpenMPT treat it like an uint8, although they treat a value of 0 as "do not force panning" and values 1...255 as "force panning" (1 = left, 255 = right). If it is indeed an int16, would that mean that a value of 0 (center) should not force center panning on a channel (i.e. use previous panning position), or is instrument panning enforced on every note like in XM?
Or is there a similar difference as when comparing panning envelopes stores with DBPro 2.x (0...64) and DBPro 3.x (-128...128)?
Second, example DBM files coming with DBPro have an undocumented MPEG chunk instead of SMPL. I think the first $numSample uint32s are the uncompressed sample sizes, which are followed by an unknown uint16 (always 0x00 0x40?). Is there actually a way to determine the compressed size of each sample? I'm asking because the usual mpeg libraries like libmpeg123 simply munch as many bytes as they can get, and you can't tell them to stop after x samples have been decoded.
Edit: I'm decoding the whole MPEG chunk into one big buffer now and then split this buffer up according to the uncompressed sample lengths, but this still gives me crippled samples. How is this supposed to be done correctly?
Last but not least I think the description text "Number of instruments in the module (up to 255)" is wrong. There's always one more instrument than this number claims.
Thanks in advance,
- saga (OpenMPT maintainer)
It depends if you mean panning as parameter of 8xx effect, or value of panning envelope point. In the first case, this is uint8, interpreted as: $00 is full left, $80 is center, $FF is almost full right ($100 would be full, but cannot be used in effect). In envelope point panning is int16: -128 is full left, 0 is center, +128 is full right.
Yes, similar, it is just different range, as parameters of effects are uint8 by definition, and they are written in the pattern as such.
AFAIK this feature was only used in those example modules. I've yet seen no module using MPEG compressed samples. Even if some exist, this feature is considered obsolete and will be never supported by DigiBooster 3. MPEG compression is encumbered with patents, also using lossy compression in a format used for storing projects being continuously edited makes no sense. There are plans for using FLAC compression instead. Of course it will be fully documented when implemented.
In fact it is not true. However it should be noted that inside DigiBooster instruments are numbered from 1 in patterns, while inside DBM0 module they are counted from 0. It may give an impression, that there is one more instrument. What makes the thing more complex, samples as given inside INST chunk, are numbered from 1 as well, so sample 0 just does not exist. This information is in fact missing in the specification, I will add it.
I also want to note that we are going to release an official C code of DigiBooster 3 loader and replayer. This code is portable, it will compile on Linux and Windows out of a box and has minimal dependencies. It will be probably licensed on BSD license. The loader is finished already, player is in the work.
Regarding the panning, I was talking about "2 bytes Instrument panning (−128 = full left, +128 = full right)." - is this also -128...128 in version 2? I'm just wondering because the panning envelopes were also XM-compatible, so I wondered if the same is true for default instrument panning.
I was just checking my code again to be absolutely sure, and I found an off-by-one mistake there in one place, which I fixed in another place by adding 1 to the number of instruments. So yes, it is correct after all, sorry about that.
By the way, is it possible that portamento effects are working slightly different from how they are known in MOD/XM?
Consider this tune...
I have an MP3 recording of it (since I can't get DigiBooster to run in WinUAE, I can't verify it myself), in which you can clearly hear three distinct notes in the first pattern on channel 9 (starting from row 52, F#...A#...A). However, when interpreting those 3xx commands just like in MOD or XM (with Amiga slides), the slide to A# only reaches A, so it sounds like only two notes instead of three.
Yes. Default instrument panning in INST chunk is stored as 2 bytes and uses [-128 .. +128] range, exactly the same as in envelopes. The only place, where panning is stored as uint8, is parameter of 8xx effect. There is no change here between DigiBooster Pro 2 and DigiBooster 3.
Yes, this is because "portamento unit" in DB3 is aligned to the music scale and is equal exactly 1/8 of a semitone interval. However some musicans told me it is too fast compared to DigiBooster Pro 2. Then I'm considering some measurements and adjusting it to 1/12 or 1/16.
This tune was made ten years ago, though, and the file header says it was made with DB2.21. So something must have already been different from MOD/XM in DB2. I'm more intersted in playing things like DB2 would play them, since that's what the majority of DBM files was made with, obviously.
Easiest would probably if I could just get DB2 to run in WinUAE here, but I'm not sure how to install the required "ReqToolsLib".
So, after finally getting DBPro 2.21 to run in an emulator, I can definitely say that portamentos are apparently working slightly different from ProTracker and similar. Otherwise I can't explain the differences that I hear when listening to that section described above in OpenMPT / xmp compared to DBPro. Maybe it's only a problem in the octaves outside the ProTracker range?