added xm #68
added xm #68
Conversation
| title: Extended Module | ||
| application: | ||
| - FastTracker 2 | ||
| - Protracker |
There was a problem hiding this comment.
Please list only applications that originated the format, not all applications that support it. It's like you list only "Adobe Photoshop" for .psd, not all possible viewers / raster image editors with kind of support .psd.
| - id: preheader | ||
| type: preheader | ||
| - id: header | ||
| size: preheader.header_size - 4 |
There was a problem hiding this comment.
You don't like prefixes proposed in the style guide that much (i.e. len_, num_, ofs_, etc)?
There was a problem hiding this comment.
Yes, I really don't like them:
1 it is a bit weird to put low-level details first and high-level last
2 combining verbose words with non-verbose ones also looks weird
There was a problem hiding this comment.
Well, could you raise your concerns in kaitai-io/kaitai_struct#140? Current "silent protest" won't get us anywhere — I still think that any standard at all is better than no standard, and until we'll discuss your objections, I would just take time to enforce it manually, i.e. by fixing your contributions. This will, in turn, will probably just annoy you, because:
- It takes longer time to get your ksys into this repository
- After that, "that guy" comes and mangles it in a way you don't like it
I see that you do a lot of interesting stuff here, and it would be bad if all that would go to waste just because we couldn't agree on some basic stuff.
I actually have an idea. Can I contact you using your mail.ru address?
There was a problem hiding this comment.
I actually have an idea. Can I contact you using your mail.ru address?
Of course you can, but why not to discuss it on GH? Have I made you angry? If you contact by email, please leave a comment on GH about that.
After that, "that guy" comes and mangles it in a way you don't like
Completely OK: it's your repo, it's OK to do what you want in it, even completely wiping it.
There was a problem hiding this comment.
If you contact by email, please leave a comment on GH about that.
Confirming, I've sent you the e-mail.
media/tracker_modules/xm.ksy
Outdated
| file-extension: xm | ||
| license: Unlicense | ||
| endian: le | ||
| encoding: utf-8 |
There was a problem hiding this comment.
Again, given that xm originated from FastTracker in early 1990s, I highly doubt that any utf-8 support existed back there at all.
There was a problem hiding this comment.
I guess it is quite safe to put utf-8 everywhere where ASCII is assummed because it is compatible with ASCII and because it is natural to think about utf-8 as about ASCII extension.
There was a problem hiding this comment.
As far as I see, there are tons of xm modules which make liberal use of non-ASCII names everywhere, usually assuming something like cp437 or some similar IBM codepage.
There was a problem hiding this comment.
I can make it an array then. But it is not very good idea - ksy descriptions are also a documentation, module name is meant to be a string, but we don't have strings of unknown encoding for now.
How about encoding: ? triggering heuristical encoding detection?
|
@KOLANICH Thanks! Finally, I've got to merge this one. |
It is not very ready (I'm stuck with problems with packed data, KOLANICH-specs@2e90f42, it surprisingly doesn't work even though it is consistent with the spec, it may be byte alignment issue (even though all the
packed_notestructs take integer count of bytes), I tried to removealign_to_call from note and the parsing finished without an error (I have not verified the result)), but instrument part is quite ready.