This sounds good to me.

I would select a more consistent, and more Csound-like naming scheme
(vstload, vstplay, vstgui, vistmidiin, vistmidiout).

As I understand it, your design permits more than one instance of the same
plugin to be used in a single Csound orchestra. Your design also permits
MIDI input to go to a VST plugin either from instrument pfields, or from
Csound MIDI input. Please correct me if either of these is not the case.

The only pitfall I can see is handling your VST GUI window events. You could
either create your own thread with its own main frame window to manage these
events, in which case you will need to synchronize your VST plugin state
with its VST GUI, or you could set your own Csound yield callback and have
your callback dispatch the window events (like the FLTK widgets do now). I
would try the latter approach first.

----- Original Message ----- 
From: "Andres Cabrera" 
To: "Csound Developers Discussion List" 
Sent: Tuesday, June 01, 2004 6:54 PM
Subject: [CSOUND-DEV:4791] VST host opcodes syntax


> Hi,
> As I said, I'll try to make VST host opcodes for csound. Does anyone
> foresee any major pitfalls or problems for doing this?
>
> Here's my syntax proposal for VSThost plugins in csound:
>
> -VSTplugins and intruments would be loaded into memory at init time with
> a global opcode such as:
> giVSThandle VSTinit iplugin, [i1, i2....ix]
> iplugin is the path and name of the vst dll.
> i1 - ix are the initial parameters for the plugin (possibly parameter
> number/value pairs)
>
> -VSTplugins would be called inside an instrument
> a1 [,a2] VSTplug giVSThandle, ain1[, ain2]
> a1 [,a2] VSTinst giVSThandle, ain1[, ain2]
>
> -There should be an opcode to open the graphical interface for the plugin:
> editVST giVSThandle
>
> -There should be opcodes for MIDI communication to and from the plugin
> kdest VSTctrl7 giVSThandle,ichan,ictrl, imin, imax [,ifn]
> VSTmidiout giVSThandle,kstatus, kchan, kdata1, kdata2
>
> optionally:
> kstatus, kchan, kdata1, kdata2 VSTmidiin giVSThandle
> VSTmidion giVSThandle,kchn,knum, kvel
>
> Any thoughts?
>
> Andrés
>

Thanks for your reply Michael, I am very enthusiastic about my project, 
and also hope to get it done...

Michael Gogins wrote:
> I would select a more consistent, and more Csound-like naming scheme
> (vstload, vstplay, vstgui, vistmidiin, vistmidiout).

ok, I'll stick with that. I guess I'm too influenced by CsoundAV... =)

> As I understand it, your design permits more than one instance of the same
> plugin to be used in a single Csound orchestra. Your design also permits
> MIDI input to go to a VST plugin either from instrument pfields, or from
> Csound MIDI input. Please correct me if either of these is not the case.

What I'm thinking is that one instance of a plug-in is created by each 
global vstinit. vstinit would be meant to be used globally outside 
instruments. The vst plugin is then accesible by all instruments by use 
of the giVSThandle. The choice to use p-fields or MIDI input would be 
defined inside the instrument, since the opcodes would send whatever 
information is passed to them.
vstinit would be meant to be used globally outside instruments

> The only pitfall I can see is handling your VST GUI window events. You could
> either create your own thread with its own main frame window to manage these
> events, in which case you will need to synchronize your VST plugin state
> with its VST GUI, or you could set your own Csound yield callback and have
> your callback dispatch the window events (like the FLTK widgets do now). I
> would try the latter approach first.

The VST GUI is a low priority, but I hope to get it done. I was thinking 
of using a separate thread, so can you explain your suggestion a bit?

Andrés