Wireless Audio Modules [BETA]

[trogluddite]

Hi All,
Finally got something a bit more useful out of my experiments with data sharing. Audio Transmitter and Receiver modules that allow sending audio streams between plugins. Nodes are given names so that you can set up 'channels' for different audio streams - each transmitter must have a unique name, but multiple receivers are allowed to tap into the same 'channel'. An 'Auto' mode for connections allows them to be easily switched on the fly.

Sorted out the problems I was having before with the DLLs - everything is now embedded, and the modules can be put into the toolbox safely.
And the best part is that in testing so far (ancient Q6700 WinXP machines!), CPU load is very low - fractions of 1% per connection (a little higher when 'auto' nodes are scanning for a connection). And latency is only a single ASIO buffer (though for some reason, it's much longer in Reaper if transmitter is on a record enabled track, and receiver is on a playbback track - some sort of latency compensation CPU optimisation, I think).

Wireless Audio 1_0_0 BETA.fsm

(172.08 KiB) Downloaded 1582 times

This is just a BETA at the moment, as testing so far has been restricted to my own machines (and I've only been writing C++ for a few weeks!). So, as well as the wireless modules, there are a couple of very crude plugin modules that are export ready - they have error reporting built in, so if you have trouble with them, hopefully there'll be some useful de-bugging info presented.

Note that they'll only work properly for plugins that are in the same VST host - so that they're sharing the same ASIO audio clock. Even then, watch your ears/speakers/headphones - if the synchronisation fails, it won't sound nice!!!

NB) Buried deep within the modules is a DLL primitive - DO NOT click the boolean true connected to the 'Embed' input, or the 'DLL Detach' link - if you do that, the code for the embedded DLL will be cleared, and you will need to reload the schematic before making VST plugin exports!

PS) Big shout to Tzarls - your tips on where to look at improving my C++ were exactly what I needed!

[tester]

Well well well, nice one. Will this also work with standalone apps?

[trogluddite]

Will this also work with standalone apps?

For audio, I'm doubtful at the moment, as a shared audio clock is essential , and ASIO won't share - but there might be a slim chance with Windows drivers (my weirdo machine has all the stock Windows audio disabled, so I haven't tried yet!).

For "random access" data, rather than streams, it should be much easier, and I've proved it in principle already. I'm hoping to get a few modules out that can share 'green' data pretty soon - the stock DLL primitive supports all the common string/number/array types directly, so the code shouldn't be too tricky, I hope.

[Tronic]

become curious ...

Sorted out the problems I was having before with the DLLs - everything is now embedded, and the modules can be put into the toolbox safely.

how you have sorted this?

[trogluddite]

how you have sorted this?

Erm - to be honest, I have absolutely no idea!
When I tried the first time, I just used the standard DLL template from Visual C++ Express 2008, and the DLLs just wouldn't embed (and 100% crashed the toolbox!). So, I started again from the VC++ example files that Malc provided when the DLL prim' was first released, and now it works!
The source files were pretty much copied and pasted from the old project. So I guess it has to be something in the compiler/linker settings of the project files - but I'm too noob with VC to really know what I would be looking for.

[RJHollins]

oh .... this could be HUGE !



Have just dL'd the 'beta' ... hope to check it out tonite.

First question, though .... the 'embedded' DLL ??? The DLL PAth module points to a location that I most likely wouldn't have I'm not sure what I'd need to do first before looking to test.

Still ... appreciate the included comments in the schematic.... that always helps

[trogluddite]

The DLL's code is embedded into the primitive (statically linked), so the .dll file shouldn't be needed, and the path will just be ignored. But don't click the boolean true on the 'embed' input of the primitive - if it goes false, the embedding is undone and you'll have to reload the schematic before exporting!
Likewise, leave the 'DLL Detatch' wireless link alone, as any trigger there also unlinks the dll code.

I'll remove those once I'm satisfied that everything's working across a good range of systems - I just left them in there so that I can tweak things easily when the bug reports start rolling in!

[billv]

Just did quick test...Seems to work fine....
..brilliant stuff...so much potential with this...Thanks Trog..
Hoping this goes beyond audio, into Midi/Ruby/Green...

[trogluddite]

Ah, that's great news, billy - music to my ears!

Hoping this goes beyond audio, into Midi/Ruby/Green...

That's the plan!
I just decided to do audio first as it's actually the trickiest to get right (ensuring everything's sync'ed properly is so critical) - getting that working means that I should have cleared the biggest hurdles already (fingers and toes crossed!).

[billv]

That's the plan!

Awesome.
Thanks for having a go at this dll componant thing Trog, and spending the time
to understand it and re-create it for easy use, for the rest of us.
I looked at it earlier in the year, found it all way too hard. gave up on it.
Cheers.