Relay LCD signals from one device to another with the same display.

[Mercury]

Hi, I have a Kurzweil K2000RS sampler from the early 90s. Because of the form factor it can be uncomfortable to program the machine for long periods as the front panel is typically vertical when on a desk or mounted in a rack. Using an angled rack would go a long way to fix this but because of the size and bulk of the machine (plus noisy fan and power transformer) that can also present challenges.
What I’d like to do is build a desktop remote controller that includes a duplicate of the front panel controls and display.

I’ve done a few upgrades to the machine including replacing the LCD Display and installing a SCSI2SD board in place of the original SCSI hard drive. In the process I got to see how things were connected to the display and front panel: https://helium.deepgreen.ca/dave/K2000R_Display/K2000R_Display_Upgrade.html

Each component, Display and Panel buttons, are connected to the main board via their own 20 pin ribbon cable. The LCD is a Toshiba T6963 based 240x64 parallel display.
I don’t have an electronics background but have done a bit of coding. The naïve idea I have is to create 2 custom boards. One installed inside the Kurzweil and the other within the remote controller with some sort of fast connection between the two preferably delivering both power and data that could be of a reasonable length (2m would be fine but 20m would be awesome so the main unit could be racked somewhere out of sight). I’m guessing that simply running two 20-pin cables externally will fail after a certain distance due to eventual capacitance, resistance and interference issues.

The internal board would be inserted internally between the main board and both the display and front panel respectively allowing the signals to pass though directly and also be duplicated and transmitted to the external board so that its display and controls are in sync. For the Desktop Remote I would build a custom panel so I could use my own choice of mechanical switches and encoders etc. I imagine that for the display it would just be relaying the signal one way from the Kurzweil to the desktop remote but the front panel would be 2 way as there are a number of LEDs that change either via direct button presses or software during the synth editing process.
Regarding power, that may be an issue. Apparently they beefed things up a bit for the K2500 series but the K2000 is well known for its barely adequate power supply. They have a 12V connector for an internal SCSI hard drive option but you had to be very careful which one you installed as it may consume too much power and not work. There were lots of reports of that being unreliable even with factory solutions. As for my unit, I replaced the built in floppy for the SCSI2SD card. Both use 5V so that was a direct swap. The original display had a separate 5V connection to power the backlight but the new display only uses 3.5V and is getting that from the 20pin cable directly from the mainboard. So there is some power budget between the spare 5V and 12V cables but weather that is enough to drive say two 3.5V micro controllers (one internal and one remote )and another 3.5V external display is an open question. Maybe I would have to forego powering the internal display when using the remote as an option.

I’m in the process of deciphering the Kurzweil’s SysEx implementation and have found some pretty good resources as this can reproduce the buttons and reading the display via MIDI. The main issue with this approach is the fact that the Kurzweil is pretty underpowered for processing the volume of messages that may be required while also playing the instrument - which you would want to do while editing and there are inherent delays . All this is pretty instant when you are using the front panel controls directly and it’s that experience I want to reproduce on the remote controller. Also, using the onboard sequencer is a non-starter due to the constance screen refreshes required.

When I’ve searched online, the closest I have found of people wanting to something similar is with the goal of capturing the actual text and/or values displayed on the LCD where for me I only want to be able to to retransmit the raw display signals, like-for-like to a remote display of the exact same type. That way thereby I leaving all the processing on the Kurzweil without SysEx clogging the process.


So my question is how feasible is this?

 

[MatrixRat]

Being a Roland JV/XV nut, I totally get why you would want to do this. How about a set of proxy buttons controllable via Midi and use a camera looking at the Kurzweil's display as a source for visual feedback.

I'm sure it's feasible to read and decode the parallel display traffic, sending the results to your display/control console for further number-crunching, just not attempted anything like that yet so am unable to offer any insights as to how.

I want knobs rather than menus to manipulate the JV on the fly and have all the foundations working however have no need to look at it's screen in the process.

By the way, the Kurzweil is of similar age to my JV and from a repair tech's perspective, electrolytic caps don't last forever so is wise to replace them all. Look closely for any signs of leakage or bulging and in particular any sign of solder mask lifting and pcb track corrosion.

 

[Mercury]

Hi MatrixRat,

I have considered the camera/proxy buttons (via MIDI System Exclusive messages) approach and that is probably the most practical with respect to skill level and device safety and would probably be sufficient for me with only one device, the Kurzweil, requiring a remote (although I do have a Peavey SP that's in the SCSI chain but it is now pretty redundant). Just sending button SysEx is fast and light weight so perfectly acceptable in this case. .... but where's the fun in that!

The caps seemed ok last time I looked when I replaced the old screen and installed a SCSI2SD but you are right, they're a ticking time bomb of hurt that I should head off at the pass.

I have been poking around this concept for a while and just found the following (old?) project that actually goes above and beyond to capture the LCD signals, convert them to instructions and then broadcast them via to bluetooth to a destination virtual LCD. If that was fully realised you could use this device on any LCD and just have to write a virtual LCD "plugin" and then be able to remote control all your (vintage ?) rack gear. You could show all the displays at once on your PC monitor. Sadly, the last update on that project was the end of 2019 so I'm not sure it's still kicking - but there is some code on his github that may be of use. He was using a feather to do both the capture/translating and transmitting but there were critical timing issue on the bluetooth side using one device so he moved to using a teensy on the capture/decoding side and then just uses the feather for bluetooth. I think he got it so what was being transmitted was just a bitmap of the screen render so you would need anything too sophisticated on the receiving end.

So that lifted my spirits a bit but I'm under no illusions this would be easy - especially as I'm a total noob with regard to electrical engineering and micro controller programming. So I'm hoping brighter minds with the same desire for this may be willing to explore this further.

Regarding the Kurzweil it's a pity in some ways because the SysEx implementation is actually very comprehensive - to the point you can actually pull bitmap screen captures off the live LCD over midi. The pity is that it's dog slow and the machine often looses the plot and is in no way suitable for rapid editing such as you could do from the front panel. The latency is about 1 or 2 seconds in some cases but that is mostly the graphics. There is a separate request for just the screen text and that can be around the 500ms mark. This can be optimised a fair bit if you cache all the graphics or reproduce them on the remote side but there are a couple of road blocks such as the on board sequencer. The screen updates are just way too frequent to even consider. There is a new software remote based on CTRLR that is in the early stages so not not optimised yet.

I was thinking I could do something like you mentioned with regard to creating an interface that avoids much of the screen diving but the main limiting factor there apart from the slow SysEx dump requests is the real time control while editing. I'm not sure it will be very snappy - or reliable. Early 90s tech has its limits I guess.

So... the camera approach may be what i ultimately end up investing in as performance is the key here but if an LCD sniffer can work it would be kind of awesome - for me, but also I'd imaging for people who have a bunch of ageing gear stored in a cabinet, rack or just out of reach that goes unused mainly due to the hassle compared to having buttons, knobs and a display right in front of you.

 

[MatrixRat]

So just thinking of the control side, say you use enough analog switch elements (74hct4016) and wire one across each Kurzweil button and drive each one via some in-house sysex over a unique Din Midi port, then you only have the latency of a single sysex decode per buttonpress. Sounds simple, the devil of detail is never far away.

I checked out DoMSnif and did not see any code for the Teensy or Feather so am completely in the dark as to the nature of the sniffing task but feel that a possible approach would be to use a Teensy to sniff display data and decode it to primitives rather than pixels-per-frame thusly minimising data payload back to your control surface/display. Perhaps some leds for the sequencer?

Might be worth looking into Teensy MicroMod's camera capability.

Used CRTLR a bit, pictures of knobs, ya still gotta grab a mouse = glorified menu-diving.

 

[Mercury]

A single button SysEx is one-way and just 9 bytes: F0 07 00 78 14 09 40 7F F7 so those I can send as much as I like and it doesn't seem to tax the Kurzweil at all - so that's not a problem, it's the requesting part that causes issues.

Maybe the public DoMSnif code is just the virtual LCD GUI?

I'm thinking I may get 2 teensies and hook one up to my spare T6963 LCD and try and get it working to show some text and graphic screens. then get the other teensy to try and intercept and decode.. then move the LCD to the second teensy and drive the display from the instructions of the first. This is before I dare start trying to tap into the Kurweil's signals and blow it up.