Transfer array between instances

[HughBanton]

PS) I also really like your version of the FlowStone header - it is such an improvement over DSPr's horrible mashup of compiler macros!

Is this the bit that's in the manual, p264, the dll 'Helpers'? I'm amazed that it can be re-worked like this in flowstone.h , nice one indeed! When I was last into using dll's (a while back now ) I just dutifully copied the 'Helper' bit and it always seemed to make things work OK.

So, are we close to a testable thing here .. using a dll prim yes? I'm guessing the planned dll inputs / outputs are to be pagesize, mapname, mapsize, frame etc. etc., if I read it correctly so far.

I suspect I'll grasp it all better when I see something in action. Hoping it continues to come into focus.

H

[HughBanton]

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

data_transfer_dem.fsm

(3 KiB) Downloaded 849 times

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.