Transfer array between instances

[HughBanton]

Does anyone know the way (there's got t' be a way ..) to transfer data from one FS instance to another?

I want to send a 'control' array from an .exe (probably) to VSTs (probably). Array size would be around 2k.

I've got such a thing working internally inside a schematic, but I reckon it would be rather neat to centralise and extract the control part and run it externally.

Am I looking at win32api or something? Assume I know nerrthing ...

H

(I'm also interested in running the control networked, from a different PC, but first things first )

[deraudrl]

Seems like we discussed 'shared memory' implementations here recently...seems like the place to start.
("Recently" defined as "since I got here" ).

I'm not finding it in a quick search. It may also have been in a tutorial or FS Guru post...

[trogluddite]

The best solution will depend on how often and how promptly you need the data to be transferred.

The simplest, but slowest, way would be to save the data to a file. The receiver would then poll for changes to this file and load the data whenever the file has been saved/modified. This would be best done with Ruby, as it has the necessary methods for testing a file's modification time, and makes it relatively easy to save/load files containing arbitrary data. This method might not be as slow as you think - Windows uses "write behind" caching, meaning that the saved data can be loaded by another instance directly from memory before the file actually gets written to disk (it might not get written to disk at all if you delete it as soon as you've read it). However, you don't want Ruby to be polling the file system too often, as this is a relatively slow process which might cause a Ruby bottleneck - but it would fine if you can stand maybe a second-or-so's delay between updates.

If you need the transfer to be more responsive than that then, yes, you'll need to start delving into the Windows APIs - in particular, something called a "MappedFile". These use the "write behind" cache mentioned above to create a special file which behaves as a chunk of memory which can be shared between applications. Anything written to the file is instantly visible to any app which has the file open for reading. You would still have to poll the file, but this can be done using a simple flag inside the file data, which can be tested as quickly as reading a normal variable.

The spanner in the works is that Ruby's Win32API library doesn't work inside VST plugins, only EXEs (contrary to what the User Guide says). To use the MappedFile technique inside a plugin, you'd have to use the DLL primitive and write a custom DLL for it using e.g. C++ in Visual Studio. I did make a start on such a beastie a few years ago, but unfortunately I ran into problems that were a bit beyond my C++ coding chops!

[HughBanton]

Most interesting, and Mapped File would seem to be the best route to take, even if I later opt for access from a remote pc. It does all appeal.

Unfortunately Trog, my C++ skills don't come anywhere near ++, more like C-- (or maybe C/99.9?) last time I tried anything serious

I did actually briefly employ DLL modules - pheww - when I first returned to FS in 2017, (I'd just flown in from Arduino Land), but I have't done much in C for ages and I'll be rustier than ever.

Still .. time on my hands for some strange reason, I might rise to the challenge!

Thanks

H

[TheOm]

but unfortunately I ran into problems that were a bit beyond my C++ coding chops!

What problems did you encounter? I have experience with c++ and the windows api, so I might be able to help

[trogluddite]

but unfortunately I ran into problems that were a bit beyond my C++ coding chops!

What problems did you encounter? I have experience with c++ and the windows api, so I might be able to help

I think what stumped me most was concurrency. So maybe the problem was not so much C++ specifically, but lack of experience at working with multiple processes/threads accessing shared data. IIRC, the prototype I linked to above is not at all threadsafe - it assumes that execution of reader and writer cannot overlap, and even the simplest case of single-reader/single-writer could potentially suffer from data corruption. I know the basics of using mutexes when I need to sync threads spawned from the same process, but cross-process synchronisation (e.g. exe to plugin as Hugh suggested) is way beyond my experience.

[HughBanton]

The more I think about it, it would be a fantastic FS asset if someone could pull this off!

At the moment It's mostly way over my head (never say never ...), but some of this MS reference already makes a bit of sense to me :

https://docs.microsoft.com/en-us/window ... and-memory

Hope it can be made to happen one day.

H

[guyman]

I almost put a bump on trog's original wireless tx/rx modules just a few days ago. +1 I'd love to see this happen.

[TheOm]

I have reworked the code a bit and added some simple synchronization, just to guarantee that the whole shared memory region is updated atomically.

[trogluddite]

I have reworked the code a bit and added some simple synchronization, just to guarantee that the whole shared memory region is updated atomically.

Many thanks - and so quickly too!
I have only had the chance for a quick glance so far, but the mutex handling doesn't look as frightening as I thought it might. I see now that I should have been using the Windows Mutex objects, where previously I was trying to figure it out using just std::mutex from the C++ libraries. Your example is a good starting point for some further research, too - so much appreciated!

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