TSX support in OpenMSX.

It doesn't really. There are a few cassette games that had to be hacked to work in CAS format that work without hacking in TSX but DSK or ROM files exist of them anyway and as you're on an emulator it's easy to use them..

Both formats have their pros and cons but the biggest pro of adding TSX to OpenMSX official build would be to stop the never ending debate about adding TSX to the official OpenMSX build.

Scenario: Marty has an original copy of Avenger. This program contains blocks that are not recorded in Kansas Standard. This user prefers to convert the tape to a digital copy so that it will last more than his ageing cassette deck, and has no means (or no will) of obtaining a cracked copy.

Marty decides to record the tape in a WAV file. Not being very familiar with the requisites, he records the WAV in 48KHz 16-bit stereo, ending up with an 80 MB file. Well it's big, but at least it works flawlessly in OpenMSX. But crap, Avenger is too hard for him, so he looks for cheats. If he changes a certain sequence of bytes, he can use infinite lives. But how to do it with a WAV?

You've left poor Marty unable to play Avenger!

Marty can, of course, convert the WAV to TSX (and realize how much shorter 50 KB is than 80 MB, and wonder why his favourite emulator does not support it), and then patch it in that format, then convert back to WAV and play in OpenMSX. If Marty learns all that, his frustration at OpenMSX not supporting that format natively in the first place will be big.

So yes, TSX is useful for Marty, an OpenMSX user.

Glad to be of service. Lol
Just my cranky old man view after having to deal with TSX files for too many years (4 years).

Using ZX Blockeditor it could be done easily but using a text editor you could find the same sequence in the CAS and edit that in the same way. However Marty is using an emulator so why not use the DSK version which loads faster? 1200 baud of TSX? 3760 baud of CAS? Dsk loading speeds? No brainer.

Analysing software is not always easy, especially when the software is protected and meant to confuse the analyst. That is why the analyst has sometimes to look for out-of-the-box and complementary ways that would assist in understanding software intricacy. One of those ways is data comparison. Therefore, a more readable format may help in better understanding what a complex piece of software does, for example, by having the knowledge of what the raw data looks like. And by raw data I do not necessarily mean code, but encoded data blocks. You cannot directly look at WAV raw data and understand what that is. You would need external tools to transform that raw data. To make things worse, if such data is encoded using a proprietary format, you might not even find a tool.

I apply data comparison on daily basis as part of my job analysing software on different architectures such as ARM and x64-86, and I have done it with software for MSX as well. So, I think I have a little of idea of what I am talking about and the possible benefits that TSX could bring. But it is hard to see the value of more readable raw data, such as the one that TSX can represent, until you put hands on that because you need it for some reason. I formerly was against TSX, but I then changed my mind when I saw the potential.

Regarding CAS vs TSX, I do not see supporting CAS already as a strong argument to rule out TSX, because TSX can be used to store data blocks that CAS cannot!

As I said before, emulator users can also be software analysts, so I see the format benefits. Obviously, we are never going to get to an agreement. Some people, like you, have a point of view, and some people, like me, have a different point of view!!!