[wdmaudiodev] Re: Naive beginner with only a concept: front filter to use a VST plugin.
- From: Don Gateley <dongateley@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Wed, 8 May 2013 17:36:35 -0700
Evert, I just downloaded the open version of VSTHost and am running it now
with my PlogueBiduleVST 'phone bidule. It's perfect as a starting point
for the user app that you describe. It's slight overkill but that's ok to
start with. All that need be changed for startes is to remove the "Input
Port" selection in its "Devices" window and connect to its input via the
hidden interface of the WDM component you describe. The "Output Port"
selection and logic would remain as is.
From there it would be a matter of stripping it of unnecessary stuff and
setting it's loaded plugin and output device up via the Properties panel of
the WDM device and supressing its GUI while leaving the loaded plugin's GUI
(subject to it being locked out for proprietary reasons.)
Finally a way providing controls to the VST plugin when its GUI is locked
out will need to be considered but that can wait.
On Wed, May 8, 2013 at 5:09 AM, Evert van der Poll <evert@xxxxxxxxxxx>wrote:
> I think it is possible to come up with a system that comes close to what
> you are proposing. It consists of two components: a WDM component and a
> user mode application.
>
> The WDM component presents a virtual audio output to the system. It has a
> hidden (proprietary) interface that allows the user mode application to
> connect to the audio stream. If the user mode application is not connected,
> the WDM component just drops any incoming audio packets.
> This is much like VAC works, except there is no virtual input (at least it
> is not publicly accesible).
>
> The user mode application receives audio from the WDM component. It can
> process the audio using VST plugins and outputs the results through ASIO or
> another user mode audio API (ASIO probably preferable because of low
> attainable latency).
> The user mode application can be made to start automatically when the
> system starts, possibly running as tray icon application. Configuration is
> done through the user mode application.
>
> It may be possible to connect the configuration part with the WDM
> component's property page. I am not an expert in that area, but it seems
> likely there are ways to do that.
>
> Evert van der Poll
>
>
>
>
>
>
>
>
>
>
>
> On 5/8/2013 4:34 AM, Don Gateley wrote:
>
> Thanks, Tim. I understand the need for an integrated, but simple, VST
> host that uses the Steinberg API for this. My reason for wanting a
> driver/device interface is not to do any low level kernel processing but
> simply to give a user a familiar way to direct output to a DSP filter via
> the "Windows Sound" control panel and to configure the plugin and real
> output device via it. Is there a path to such a driver interface that
> doesn't involve kernel mode (other than perhaps as a hidden bridge)? I
> clearly misdirected my query. Can you suggest a forum or list more
> appropriate?
>
> Even though I am a programmer I am not capable of programming this
> myself. I was in real time embedded control, not Windows development. I
> work at a different level these days, audio DSP applications, and I want to
> explore pulling together the necessary expertise to do something that I and
> probably others would find useful both for development and deployment of
> audio processing functions on Windows which is much less a kludge than what
> is now required.
>
> Thanks again.
>
>
> On Tue, May 7, 2013 at 3:11 PM, Tim Roberts <timr@xxxxxxxxx> wrote:
>
>> Don Gateley wrote:
>> >
>> > I would like a WDM front filter that is configurable to the extent of:
>> >
>> > 1) naming the path to my VST plugins directory,
>> > 2) naming a single VST plugin to insert as a filter,
>> > 3) naming a real audio device to receive the output and
>> > 4) specifying parameters to the VST plugin and opening it's GUI.
>> >
>> > In my first usage it would name and utilize the PlogueBiduleVST plugin
>> > which is an entire framework for building up more complex flows and
>> > processes.
>>
>> VST plugins are user-mode modules. They're just DLLs. There's no
>> kernel code involved, so WDM doesn't apply. At the bottom end, the
>> hosting application pumps the resulting audio feed into the Audio Engine
>> for rendering to a speaker, but there must BE a hosting application.
>> They can't run on their own.
>>
>>
>> > I am successfully doing this now via the Virtual Audio Cable and
>> > VSTHost applications but would like to considerably simplify the
>> > mechanism for use by others with a wish to filter Windows audio in a
>> > general and flexible way.
>>
>> There's really no easier way to do this. You are trying to connect two
>> incompatible audio worlds here, so you're always going to need an ugly
>> adapter plate. That's what VAC is doing for you. Even if you made your
>> own VAC clone, you can't load user-mode DLLs in the kernel, and you
>> can't do UI stuff from the kernel. You'd still have to have the VAC
>> clone pipe the data to a VST host of some kind.
>>
>> --
>> Tim Roberts, timr@xxxxxxxxx
>> Providenza & Boekelheide, Inc.
>>
>> ******************
>>
>> WDMAUDIODEV addresses:
>> Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
>> Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
>> Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx
>> ?subject=unsubscribe
>> Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
>>
>> URL to WDMAUDIODEV page:
>> http://www.wdmaudiodev.com/
>>
>>
>
Other related posts:
