Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Transfer array between instances

For general discussion related FlowStone

Re: Transfer array between instances

Postby HughBanton » Sat Nov 07, 2020 6:59 pm

trogluddite wrote: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 :oops: ) 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
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Transfer array between instances

Postby HughBanton » Tue Feb 16, 2021 11:47 am

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 :D

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 717 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.
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Previous

Return to General

Who is online

Users browsing this forum: No registered users and 52 guests