tulamide wrote:What exactly are the benefits of sending audio streams between plugins on the same host?
No worries mate, no offense taken at all, and a good question - I'm quite surprised that you're the first to ask!
Well, taken in isolation, you're quite right, any decent VST host these days can route audio almost any way we please - my favourite host is Reaper for that very reason, because it's routing insanely flexible!
But, my programming is very pragmatic - very rarely do I write something that I don't see a use for - so here's a few of my thoughts...
1) Maybe I shouldn't have said "Audio"That was lazy! I should maybe have said "stream of float values". The plugin I want to use this in may give an example...
Many years ago I wrote a plugin called 'Soopa Doopa Loopa' (should still be there on the SM forum). I use it for live audio looping, mostly with my bass guitar. I use tap tempo a lot, and much messing with odd time signatures and polyrhythms - so, to cut a long story short, using VST host beat/bar sync just doesn't do what I need (I'm controlling everything with my feet for a start!).
I want to make it modular - to add more loops, just add more instances of the plugin. But then you have to sync them somehow (sample accurately!).
I CAN already do this - by routing a couple of timing signals (float streams) via extra audio channels - but it's a PITA.
- Lots of extra routing to do when adding a new instance.
- The entire signal path for the clocks must not affect the number values - just a slight knock to a fader can ruin the data!
- The signals include values WAY outside the -1.0 to 1.0 value range for audio...
- ...so they are LOUD and sound awful if you accidentally route them to the speakers!
These new modules are part of the solution - a master clock can transparently get its signals to the loopers without involving the host at all - the host just acts as a 'tape recorder' for the output, which is what I want.
So, by saying "Audio", I was putting these modules inside a box that hides some alternative uses.
2) Audio routing = A choreSometimes I feel that all the routing possibilites in a modern host can actually be a PITA - setting up a simple side chain for a compressor, for example. If a signal just needs to get from A to B without having to remember which faders might affect the level, what is pre or post fader etc. etc., I kind of like the idea of just doing that - like plugging in a patch cord that bypasses the complexity of the host's mixer channels. And some people's favourite host might not allow anything beyond stereo audio channels, or have limitations on where you are allowed to route things.
3) It's a stepping stoneAs I was saying to tester, much of the code behind this is multi-purpose. IAC for "random access" data is certainly possible, and even audio might be with the correct buffering. Getting this uploaded in its primitive state will iron out a lot of the problems that will be tricky to deal with once it becomes more complex. I chose to do audio first precisely because the demand for CPU load and precise synchronisation are so critical - a very good test of the stability of the code.
The Windows API objects that the code is based around might also allow us to add other features that FS lacks - streaming of very long audio files, for example.
4) The folks on this forum are so crazy!The modules aren't really intended as a 'finished product' - they're just another tool that FS users can put in their toolbox and build into their cool new gizmos. I have no doubt that some folks here will find uses for them that I would never have dreamed of, or even thought possible - it's one of the reasons I like this place so much!