I finally followed up on Trog's suggestion about saving data to a file in one FS item, and then asap reading it back in another. He said it might be slow, and since that brought to mind some kind of 'floppy disk speed' scenario I figured it wouldn't be good enough and I didn't pursue it back in November.
Wrong! Check out the attached. What I have here is, firstly, a text box that's automatically written to a file named 'test.txt' *. And whenever the text is changed it simultaneously sends a MIDI Sysex 'trigger code' - which can be any hex code you like (<F7) - to tell the receiver that the file has changed, to read it and then to delete it. (Disconnect the Ruby delete module if you want to check that test.txt ever really existed!) As you'll see you can type into the send box and it near-instantaneouly (..in human terms) appears in the receive box. Magic.
In practice (and in Alfa-land I've already checked this works) you can communicate the MIDI trigger via an internal virtual MIDI port link, such as loopMIDI (
http://www.tobias-erichsen.de/software/loopmidi.html ) - works perfectly.
So you make the Transmit side into, say, an .exe, with a loopMIDI output, and the Receive side needs the same loopMIDI input to get the read-trigger. I've had this working with a 'floating control surface', which writes a 12k file, and it still seems instantaneous. Floppy disk it is not
I imagine a bi-directional scheme ought to work as easily.
Trog suggested that if this can be made to work fast enough then test.txt would be read directly from an intermediate buffer, and might never actually get written to C:\ .. not sure how you'd prove this one way or the other - any ideas?
H
PS * This
does write a new directory and a 1k file, to your drive C, if you start typing into the text box - harmless, but avoid if you find that uncomfortable.