Yes, this should happen. Anything about "when" or "how", I'll get back to later (though I don't see any reason why it can't be a 12.10 feature).

not sure if it's actually 100% correct to be honest though because I used Google translate!

It probably isn't, unless you translated from Japanese. Machine translation into / from Japanese and Korean, except for between each other, tends to be good enough to understand what's being said but usually quite far from accurate. Although maybe they've gotten better in the last few years.

In old-formats, a pack could come with tilesets and music built into it (in the NXP file). Either could also be put into the global installation. To do this in old formats, the creator must have released the music / styles standalone; they could not be extracted from an NXP file (or rather: no tool to do this was provided; someone with sufficient coding ability could of course extract it).

In new formats, both are always globally installed and there is no "prevent anyone else from using this" mechanism other than asking nicely.

Just to confirm: You are clicking "Add requirement" after selecting the condition / quantity, correct?

I spotted this as a potentially unintuitive aspect of the UI, but otherwise can't reproduce this, even using that exact level.

I'm not sure what the proper terms for each actually are, but there's "how many bits is each sample made up of?" - this is the 8 bit, or 16 bit, or 24 bit. Then there's - for compressed audio formats (you could measure this for uncompressed ones too, but it's kinda meaningless there except in terms of calculating file sizes from quality / length or vice versa) - "how many bits or bytes are used for each second of audio?"

In uncompressed audio, each sample really is equivalent to a pixel. The sample is a single value, which could be an 8 bit value (-128 to 127; or 0 to 255), a 16 bit value (-32768 to 32767), a 24 bit value (-2^23 to 2^23-1). In for example a 44100Hz audio file, one second of mono audio would be made up of 44100 of these samples (double this for stereo - one for each speaker - etc). Similar to how if you had an image file where 44100 pixels would make up 1 metre when translated into physical space, one metre would - of course - be made up of 44100 pixels. In such a case, the bit rate would just be (sample depth) * (frequency) * (channels) - for 44100Hz, 16 bit, 2 channels (stereo) that'd be 44100 * 16 * 2 = 1411200 bits per second (~1400kbit, or about 175KB for every second of audio).

In compressed audio, this gets reduced to the target bit rate - whether this is a hard and fast "always hit it exactly" or just a "use it as a guideline" depends on the specific format - by using a combination of data compression algorithms, and reducing the quality to make the data more compressible (for example - let's say we have a sequence of samples "100, -100, 99, -101, 99, -99" - changing this to "100, -100, 100, -100, 100, -100" is almost indistinguishable to the human ear, but can compress much better). This is why, even at equivalent bit depth and frequency, a lower bit rate compressed audio file sounds worse - and why, other than by changing those factors, you can't get a lower bitrate on uncompressed audio.

I've had to learn / figure out a lot of this while working on Tiel Attack, as a significant portion of its sound code is custom. In particular, the data files only contain a list of notes + durations + "sound type" + loop points for the music, with the game itself generating actual audio data from this. (The sound effects on the other hand are prerecorded, though due to the exact implementation Tiel Attack does work with their data at a relatively low level.)

allows multiple packs ... to share music.

This is actually a big part of why music isn't stored with packs.

It's known that this is possible. While this is definitely a "don't do this", I kind of feel it's one of those ones that isn't worth making a special effort to prevent. Absolute paths have no explicit prevention either - it's simply that the way the code is written in general (in particular, that upon startup NeoLemmix figures out the absolute path of the NL folder, and it looks for music files by combining this path + "Music" + the music name) doesn't work with an absolute path. In fact, relative paths working was initially an unintended side effect too - then when I realised the usefulness of it, I instead decided to make it an explicitly supported feature.

To those wondering what piece grouping is: it basically means you can select a few terrain pieces in the editor, "group" them, and they now act as a single piece. This can be useful when you've created a complex structure out of smaller pieces, and want to ensure it's only moved as a large group, not as individual components. It can also be useful when trying to do particularly tricky stuff with erasers.

Note that a piece group cannot mix steel and non-steel (but erasers are exempt from this rule). It must be either all steel, or all non-steel. Similarly, it won't become a mix of one-way-capable and not-one-way-capable terrain - there's only a single one-way flag for the whole group. Keep these limitations in mind.

Uploaded editor V1.24.

This fixes some issues relating to the level ID, as well as a bug relating to deleting talismans.

https://www.neolemmix.com/download.php?id=428

(For those of you following Discord - this update does not yet enable piece grouping. That should be coming, now, but it isn't here yet.)