WYZ music file format

Gracias [WYZ]!
By "early" do you mean incomplete or incorrect?
Is it likely that you will update the file format soon?
Otherwise, if you can point me to the code that generate de .MUS file from .WYZ, perhaps I can reverse engineered the actual format.

Is this the latest version of the player?
Is it more recent than the one available in the WYZTracker package (https://github.com/AugustoRuiz/WYZTracker/blob/master/AsmPla...) or the one used by mvac7 for its C language player (https://github.com/mvac7/SDCC_WYZplayer_Lib/blob/master/sour...) ?

Thanks to the creator of the format and the player, for sharing their work with the community. :)

For the moment, I assume that the music was made for a 50 Hz machine, so on 60 Hz ones, I skip 1 frame out of 6.
If the frequency information used to create the music is stored in the WYZ format, I could adapt my player accordingly.

I am interested in this new version. If I can get the data format, I should be able to properly rework the integration of WYZ into MSXgl.

For the frequency flag, any bit is good for me. I just advise you to keep bit #7 for a flag that you would need to read very often because it is the cheapest to test. We could use bit #6 for example.
What value have the unused bits in the header currently? If they are set to 0, it would be best to make 0 the default frequency. All the WYZ music I've listen seems to have been made to be played at 50 Hz (PAL), so we could say: 0=50 Hz, 1=60 Hz.

There is another improvement that I think is very desirable, but would require a lot more work: storing table addresses as offsets rather than absolute values.
Currently, you can't load a WYZ music anywhere in memory and have the replayer play it. We have to know in advance where the binary is going to be put or compile the music with the rest of the program. This is quite limiting.
If these tables were stored as offset from the beginning of the file (as in the VGM format), it would be enough to initialize the music with the address where it is in memory, and the addresses of the tables would be calculated at that time by adding the offset.
This is a change of format that would make the old music incompatible, but it would make this format very much easier to use.

Thanks. In the meantime, I have already ported the 47d version to be compiled with the SDASZ80 assembler used by SDCC.

What I am talking about will not change the data size at all. It is just a matter of replacing addresses in absolute value (A010h for example) in offset compared to the beginning of the compiled WYZ data (start + 0010h for example). The only extra cost would be a slightly longer initialization code since the absolute addresses would have to be recalculated according to the start address of the data and the offset.

This is how the VGM format works for example. It allows to put a music anywhere in the memory space of the Z80 and to play the music by giving to the replayer only the address of the beginning of the data. All the other addresses are dynamically determined during the initialization.

It's not a big problem (especially since it already works in MSXgl ^^), but it's less convenient to have to "compile" the music to play it.

Thanks a lot! It's awesome what you manage to achieve with only 3 channels. :)

Do you have an exemple of use of the player in assembler?

@santiontanon Thanks.
@jltursan & @aoineko yes, There is a 6-channel player. with limitations (Sawtooth is only usable in one channel of the 1st PSG)This is an example