If what you need is a stronger signal, wouldn't a midi signal booster do the trick? searching the internet i found this https://www.bhphotovideo.com/c/product/423667-REG/JLCooper_MLA_XLR_MLA_XLR_MIDI_Line_Amplifier.html

I also like MIDI for its efficiency, it doesn't waste resources and it's optimized down to the last bit, too bad this is going to change in MIDI 2.0 when using JSON.

That MIDI Line Amplifier is quite expensive. Any MIDI Thru box (with its own power supply) will work.

As far as I can see from the TG100's service manual, it used a standard MIDI input circuit based on the 6N137, so it should work with any MIDI output. At the moment, I have to conclude that either the MIDI output or the MIDI cable or the MIDI input is broken, and you have to test with other devices/cables to find out.

I'm in the process of returning to try a new one as it appears the midi out of this one is bad. I'll post an update here when I test the new one.

[quotePost id=15201]I also like MIDI for its efficiency, it doesn't waste resources and it's optimized down to the last bit, too bad this is going to change in MIDI 2.0 when using JSON.[/quotePost]

A DIN port can transfer 100 10-bit bytes every 1/32 of a second, or 50 10-bit bytes every 1/64 of a second. That's still a lot of data. For context, the guitarist Steve Vai taps out at 20.8 notes per second, leaving over 100 10-bit bytes for each of those notes. Just spitballing here but couldn't 2.0 increase the message length from 10 bits per byte to 16 per byte
(to move to even subdivisions of the common 32 and 64 bit words modern processors like to deal with)
and then update the protocol to a messaging system where a 16-bit mode byte
(where the 16th bit flags that a new mode is being set, so 2^15 possible values (32,768))
can signal that a certain type of stream will follow, for instance a note stream, and then all the bytes that follow will have 2^15 values (because the 16th bit would trigger a new stream mode).
So then for a note stream, with 50 bits per 1/64 of a second, we could trigger that a note stream is coming (50 - 16 = 34 bits left) and produce 2 bytes in the remainder of that 1/64 of a second ( 34 - 2x16 = 2 <-- meaning it takes slightly less than 1/64 a second)
and use those 2 bytes of 2^15 resolution each to encode pitch and expression (usually velocity). Those 30 bits could be split up any number of ways, for instance 20 for pitch and 10 for velocity, or 18 for pitch and 12 for expression, etc. The point is it would be a lot higher resolution than the current 2^7 (128) for pitch and 2^7 for velocity.

Would there still be perceivable stepping for note bends? Yeah. 1/64 of a second is still a perceivable gap to a human. But it would be much more subtle and the pitch differences could be much slighter. A protocol update like this would allow DIN cables to still be used with a significantly upgraded resolution, and it would be trivial to scale this type of protocol in a way that a higher bandwidth connector, such as USB, could transfer even higher resolutions for all the data bits within the same protocol.

That's the route I would have tried to take if I was part of designing the new protocol.

I got another one of these keyboard to test and the DIN port didn't work on that one either. Also the Alesis support never got back to me to resolve my issue with the first one and the price of this keyboard dropped $50 (almost 25%) from the official Alesis dealer on Amazon a few days after I contacted them about the issue. I don't think it's unreasonable to assume this could be a defect across the entire MKII product line.

If you get one of these products test the DIN port immediately.