I think it's important to decide now about the FLTK threading
issues. John Ramsdell can implement the necessary changes
to make it thread-safe.  Let's do it!


Dr Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Victor Lazzarini  writes:

> I think it's important to decide now about the FLTK threading
> issues. John Ramsdell can implement the necessary changes
> to make it thread-safe.  Let's do it!

Michael and I are corresponding privately on this topic.  We are
sorting out the situation with VST plugins, and wrinkle I had not
previously considered.  We'll get back to you all when the two of us
think we have a design that allows libcsound to handle the three cases
of console Csound, GUI Csound, and VST plugin Csound.

John

Wouldn't MacCsound also be one case to consider?

At 16:34 19/01/2005, you wrote:
>Victor Lazzarini  writes:
>
> > I think it's important to decide now about the FLTK threading
> > issues. John Ramsdell can implement the necessary changes
> > to make it thread-safe.  Let's do it!
>
>Michael and I are corresponding privately on this topic.  We are
>sorting out the situation with VST plugins, and wrinkle I had not
>previously considered.  We'll get back to you all when the two of us
>think we have a design that allows libcsound to handle the three cases
>of console Csound, GUI Csound, and VST plugin Csound.
>
>John

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

i will be corrected if wrong, but I think both the MacCsound "Cocoa" GUI
and the various other GUI frontend (inc.any crossplatform FLTK-gui) 
"csound"s require a similar libcsound,
which wraps the FLTKUgens and the audio i/o in protected threads.

Do i misunderstand?
CharlieB
.
On Jan 19, 2005, at 11:58 AM, Victor Lazzarini wrote:

> Wouldn't MacCsound also be one case to consider?
>
> At 16:34 19/01/2005, you wrote:
>> Victor Lazzarini  writes:
>>
>> > I think it's important to decide now about the FLTK threading
>> > issues. John Ramsdell can implement the necessary changes
>> > to make it thread-safe.  Let's do it!
>>
>> Michael and I are corresponding privately on this topic.  We are
>> sorting out the situation with VST plugins, and wrinkle I had not
>> previously considered.  We'll get back to you all when the two of us
>> think we have a design that allows libcsound to handle the three cases
>> of console Csound, GUI Csound, and VST plugin Csound.
>>
>> John
>
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth

Victor Lazzarini  writes:

> Wouldn't MacCsound also be one case to consider?

Yes, any Mac specific issues will be need to be considered.  Let us
figure out the Windows situation, and then we'll get back to you
looking for help with Macs.

John

> At 16:34 19/01/2005, you wrote:
> >Victor Lazzarini  writes:
> >
> > > I think it's important to decide now about the FLTK threading
> > > issues. John Ramsdell can implement the necessary changes
> > > to make it thread-safe.  Let's do it!
> >
> >Michael and I are corresponding privately on this topic.  We are
> >sorting out the situation with VST plugins, and wrinkle I had not
> >previously considered.  We'll get back to you all when the two of us
> >think we have a design that allows libcsound to handle the three cases
> >of console Csound, GUI Csound, and VST plugin Csound.
> >
> >John
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth

Charles Baker  writes:

> i will be corrected if wrong, but I think both the MacCsound "Cocoa"
> GUI and the various other GUI frontend (inc.any crossplatform
> FLTK-gui) "csound"s require a similar libcsound, which wraps the
> FLTKUgens and the audio i/o in protected threads.

I wonder how the non-FLTK thread are synchronized in Csound
applications.  For now, I am just focusing on the threads that access
FLTK.

John

i still advocate using a generic control system at the 'csoundlib' 
level.  i think FLTK opcodes could be modified to 
go through the API and still be backwards compatilble.  something like:

the API would have to include some FLTK creation functions.  Then 'host' 
applications [including console versions] could create the widgets 
[FTLK or maybe even something else if certain developers might think they are 
too ugly or something].  host application would do its own threading.

if all this is unclear i would be happy to provide a more detailed example 
of what things would look like on the user, csoundlib, and hostapp sides.


and for the record,
what i do in maccsound is run the GUI (carbon not cocoa) stuff in the 
application thread and 
all of csoundlib in another [the audio callback for real-time apps]


-m




On Wed, 19 Jan 2005, John D. Ramsdell wrote:

> Victor Lazzarini  writes:
>
>> Wouldn't MacCsound also be one case to consider?
>
> Yes, any Mac specific issues will be need to be considered.  Let us
> figure out the Windows situation, and then we'll get back to you
> looking for help with Macs.
>
> John
>
>> At 16:34 19/01/2005, you wrote:
>>> Victor Lazzarini  writes:
>>>
>>>> I think it's important to decide now about the FLTK threading
>>>> issues. John Ramsdell can implement the necessary changes
>>>> to make it thread-safe.  Let's do it!
>>>
>>> Michael and I are corresponding privately on this topic.  We are
>>> sorting out the situation with VST plugins, and wrinkle I had not
>>> previously considered.  We'll get back to you all when the two of us
>>> think we have a design that allows libcsound to handle the three cases
>>> of console Csound, GUI Csound, and VST plugin Csound.
>>>
>>> John
>>
>> Victor Lazzarini
>> Music Technology Laboratory
>> Music Department
>> National University of Ireland, Maynooth
>
>

Hi Matt,

Thinking out loud, is this something we can do more simply, perhaps more 
simply? 

Say, maybe add a generic function, like csoundHostMessage(char * 
messageName, char ** values).  The host then could do with the messages 
what it wishes. For FLTK, it could be something like:

csoundHostMessage("FLTK_create_widget", ["window", "name of window", 
"etc."])

Hosts would have their own implementations of the csoundHostMessage and 
could then be enabled to respond to those messsages or not. 

Having a generic system where only strings are passed would allow for 
some degree of future-proofing.  Also, opcodes could be compiled and 
distributed with different hosts and if the host isn't compiled to use 
those messages things the user can be alerted. 

An extra opcode, csoundhostmessage, might be nice to have as well, as 
users can then manipulate messages they know (a bit dangerous, but 
potentially useful).

Perhaps also there can be host plugins that can add themselves as 
hostMessage handlers, but that might go into the realm of 
over-architcture. =)

Any thoughts?
steven


Matt J. Ingalls wrote:

>
> i still advocate using a generic control system at the 'csoundlib' 
> level.  i think FLTK opcodes could be modified to go through the API 
> and still be backwards compatilble.  something like:
>
> the API would have to include some FLTK creation functions.  Then 
> 'host' applications [including console versions] could create the 
> widgets [FTLK or maybe even something else if certain developers might 
> think they are too ugly or something].  host application would do its 
> own threading.
>
> if all this is unclear i would be happy to provide a more detailed 
> example of what things would look like on the user, csoundlib, and 
> hostapp sides.
>
>
> and for the record,
> what i do in maccsound is run the GUI (carbon not cocoa) stuff in the 
> application thread and all of csoundlib in another [the audio callback 
> for real-time apps]
>
>
> -m
>
>
>
>
> On Wed, 19 Jan 2005, John D. Ramsdell wrote:
>
>> Victor Lazzarini  writes:
>>
>>> Wouldn't MacCsound also be one case to consider?
>>
>>
>> Yes, any Mac specific issues will be need to be considered.  Let us
>> figure out the Windows situation, and then we'll get back to you
>> looking for help with Macs.
>>
>> John
>>
>>> At 16:34 19/01/2005, you wrote:
>>>
>>>> Victor Lazzarini  writes:
>>>>
>>>>> I think it's important to decide now about the FLTK threading
>>>>> issues. John Ramsdell can implement the necessary changes
>>>>> to make it thread-safe.  Let's do it!
>>>>
>>>>
>>>> Michael and I are corresponding privately on this topic.  We are
>>>> sorting out the situation with VST plugins, and wrinkle I had not
>>>> previously considered.  We'll get back to you all when the two of us
>>>> think we have a design that allows libcsound to handle the three cases
>>>> of console Csound, GUI Csound, and VST plugin Csound.
>>>>
>>>> John
>>>
>>>
>>> Victor Lazzarini
>>> Music Technology Laboratory
>>> Music Department
>>> National University of Ireland, Maynooth
>>
>>
>>
>
>
>

"Matt J. Ingalls"  writes:

> if all this is unclear i would be happy to provide a more detailed
> example of what things would look like on the user, csoundlib, and
> hostapp sides.

Matt, I would still very much like to hear your answers to the
following questions about the Csound 5 library that implements the
Csound API.

* Do you see a need to make its FLTK routines thread safe?

* Should a thread safe version of the library be usable to build both
  a console version of Csound, and an FLTK-based GUI version of Csound?

* Do you see a need to provide a means by which the library knows if
  it is to be used in a console version of Csound or a GUI version?

* If your answer is yes to all of the above, by what means to you
  propose the library become aware of the mode in which it is to be
  used? 

John