It's very simple. Csound calls csoundYield() every kperiod. This in turn
calls the csoundYieldCallback_ function pointer, which the API user can set
using csoundSetCsoundYieldCallback. Currently, Csound calls the default
implementation of this callback, CSOUND_YIELD(), that simply calls
Fl::wait(0) to dispatch messages for the FLTK widget opcodes and function
graphs.

In other words, every kperiod, Csound polls for FLTK window events and
dispatches them.

You would define your own csoundYieldCallback, which would look at the
window event queue for your own platform or windowing toolkit, and dispatch
any pending messages, then ALSO call Fl::wait(0) (I think). Or maybe
Fl::wait(0) will work for non-FLTK window events also, in which case you
wouldn't have do anything at all.

I think this is simpler than setting up a separate thread, and it removes
any need for synchronizing  between threads.

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


> 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
>

When the time comes, I'll give your suggestion a try. It makes sense to 
poll events every k-period. I guess that mean that there would have to 
be a 'buffer' when more than one event occurs in a k-period. I'll have a 
look at csoundYield().
Thanks for all your help!

Michael Gogins wrote:

> It's very simple. Csound calls csoundYield() every kperiod. This in turn
> calls the csoundYieldCallback_ function pointer, which the API user can set
> using csoundSetCsoundYieldCallback. Currently, Csound calls the default
> implementation of this callback, CSOUND_YIELD(), that simply calls
> Fl::wait(0) to dispatch messages for the FLTK widget opcodes and function
> graphs.
> 
> In other words, every kperiod, Csound polls for FLTK window events and
> dispatches them.
> 
> You would define your own csoundYieldCallback, which would look at the
> window event queue for your own platform or windowing toolkit, and dispatch
> any pending messages, then ALSO call Fl::wait(0) (I think). Or maybe
> Fl::wait(0) will work for non-FLTK window events also, in which case you
> wouldn't have do anything at all.
> 
> I think this is simpler than setting up a separate thread, and it removes
> any need for synchronizing  between threads.