It is the season of crap ideas

OK...here's another one:

How about a Standalone --> VSTi utility

A while back I asked if a wrapper was possible to wrap up standalone applications to use as a VSTi. I think this might have been laughed off at the time but here's a new 'twist' to the idea....

Several appications have become VSTi's this lately that have not used the conventional way of having the entire instrument open up inside the host.

Fruityloops and Vaz 2010 both use a little VST utility inside the host that links to the standalone and opens it up at the touch of a button. The utility basically routes all midi and audio outs from the standalone application to the hosts inputs (well....I assume that is what is done) and syncs the applications transport controls to the hosts. Obviously there is more to it than this but to the general user (like myself) thats how it appears to work.

I am thinking that a utility could be made that acts like the VST linking utility that these two VSTi's use, except that it can be used with any standalone application to effectively make it a VSTi.

My original idea of a 'standalone wrapper' was maybe a bad idea as the wrapper would have to have been able to emulate windows...I understand this.....but I don't see why this new idea would not work.

You could have anything running inside your VST host. Cubasis running inside Fruityloops, Recycle, Remix, ReBirth, Reason, Soundforum synth, Beatslicer, the ohmeforce free standalone fx, Vaz Plus (v1) etc.

You could also use it to have non-sound producing applications available directly from your host. Imagine having your CD single cover art displayed using Microsoft Paint as soon as someone opens your project, or having your sample converter available in your rack right next to your sampler (you could even open up your converter from your sampler if you own vsampler ), or Microsoft Word/Wordad to display a word file for some reason this may be useful, or IExplorer to open your bands web-site. All applications would automatically load when you open a project. Well, I don't know what people would use this for but maybe something.

Anyway, there my idea

ideas are thoughts seeking fruition.

I think it's a good idea.

How would the plugin access the data from the standalone program?

AFAIK, functionality such as ReWire and the mini plugins that stream an apps output function because the app provides access to it's data. I would have thought that if you try to hack your way in to an app's data as it's running you're gonna get all kinds of access violations and crashes.

The only possibilty I can think of is trying to piggyback the audio drivers - but then you'd need multi-output drivers/soundcard (else you'd feedback) and if that's the case there's already an app out there called "virtual audio cable" or something - I think it's like Hubi's MIDI loopback but for audio ports.

NB - you can already call platform specific stuff from plugins - e.g. some plugins provide links to access the devs website - clicking it brings up IE or whatever and goes to the website.

regards,
dunk

i also suggested this and two people who should know said it wasn't possible but who knows...

I don't understand how this wouldn't be possible because it only needs to:

1 - Be able to start windows applications .exe file from within the VSTi. This does not mean it has to host them, only be able to start and close applications.

2 - Be able to route midi information from the host to the standalone application. This should be possible as we have applications that are capable of doing this right now (e.g. MidiOx and Hubi's). Surely the workings of midi routing programs like this can be coded into a VSTi.

3 - Be able to route audio from the standalone application to the host. ReWire technology can do just this so why can this not be built into a VST linking utility.

I admit I know nothing about the technical side of VST or coding but if it were possible to do something like this I think it would be a great thing.

Alex: your claim that the VAZ 2010 (and Modular) VSTi "links to the standalone and opens it up at the touch of a button" is not true, it's just a different structuring of the UI.

To do what you suggest there would need to be a tunnel from a virtual audio driver to a VSTi stub. Due to the need to use shared memory of whatever for this and the inevitable process contention it would almost certainly suck anyway...

(Besides is the VAZ Plus 2 upgrade too expensive? )

MadGav wrote:

Alex: your claim that the VAZ 2010 (and Modular) VSTi "links to the standalone and opens it up at the touch of a button" is not true, it's just a different structuring of the UI.

OK, I see. I wonder if Fruityloops VSTi is the same. The reason I thought this is because you cannot open both the FL VSTi and the standalone at the same time (i.e. you cannot use FL VSTi inside FL standalone) so I assumed it meant that they were one and the same thing and the VSTi part was just a linking device to the standlone. Well...that proves me wrong. Maybe I should give up on my crazy ideas

MadGav wrote:

To do what you suggest there would need to be a tunnel from a virtual audio driver to a VSTi stub. Due to the need to use shared memory of whatever for this and the inevitable process contention it would almost certainly suck anyway...

That's a shame. Damn I am living in a dreamworld

MadGav wrote:

(Besides is the VAZ Plus 2 upgrade tooxpensive? )

No way man...its a bargain . Vaz is one of the best VSTi's out there and at these crazy prices I reckon no-one should be without a version of Vaz in their vstfolder

I agree this seems a questionable concept, but was just wondering if it might be possible to create a 'dummy' ASIO/WDM device and intercept all ASIO/WDM commands related to it ('wrapping' a designated program) instead of using a virtual audio 'pipe', and if so, whether this might be any more efficient with respect to process contention etc?

However, respect to MadGav, I suspect he's thought of this....

from a developer point of view...

yes this kind of thing is possible. The two applications would have to have a agreed method of communication... using windows messages(PC only, tho Macs must have some low level messageing system too!), TCPIP to 127.0.0.1, named/anonymous pipes, etc. Then having an agreed protocol through the transport.

You could use shared memory (most efficient), or common files (slow). In windows, it is possible to get a process to run in the process space of another application (but your virus checker may notice this and raise an alarm).

It would be a lot of work for little return, depending on what it is used for. Some Apps, like Console, are effectively COM objects, and depending on whether you fire up the standalone, the Dx/Dxi or Vst/Vsti, an object is instantiated. I assume that FL works in a similar way.

If an open standard were developedm then this could be an interesting move, however, the VST structure of using dlls is more efficient - since the new process is loaded into the address space of the host app, and functions are called as if it were part of the host, borrowing the same memory space. No extra process overheads..Also the 'protocol' is agreed/set out in the API.

Hope that helps!!
(takes anorak off)
DSP