First of all do you really need different threads? It may simpler for the host to call csoundCompile, then call csoundPerformKsmps and read the audio out of the spout buffer each time. In this mode, there is only one thread, the host thread, and the host drives the Csound performance. If the host buffer and the Csound buffer are different sizes, you can use 2 sets of buffer indexes and only call csoundPerformKsmps whenever spout has been consumed. This is how CsoundVST works (see CsoundVST::process()).

If you do need threads, then let Csound run in 1 thread and the host run in 1 thread. Two monitors (or mutexes) can be used to synchronize on the audio buffer. The host waits on the host monitor. Csound writes spout, releases the host monitor, and waits on the Csound monitor. The host proceeds, does whatever it is doing to consume spout, and then releases the Csound monitor and waits on the host monitor again. This causes the 2 threads to take turns producing and consuming spout.

If the host buffer and the Csound buffer are different sizes, again you can use 2 sets of indexes, one set for the host and one set for Csound. or you can copy spout into a queue and have the host copy audio out of the queue. In either case Csound will not release the host monitor until it has enqueued enough audio for the host's buffer.

The first method is simpler to write but the second method is practically as efficient since on contemporary operating systems switching threads, locking and unlocking monitors, etc., are very efficient.

Regards,
Mike

-----Original Message-----
From: Iain Duncan 
Sent: Aug 20, 2005 12:54 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Problems with csoundTableGet()

Istvan, ( or anyone else ), would it require less in the way of 
protection to get results out of csound using the inchannel and 
outchannel callback routines? Or will I still be in the same boat as far 
as getting result values from csound in other threads?

In general, what would be the recommended way of getting a given number 
of values in and out on every kpass given a multi-threaded app?

Thanks
iain

Istvan Varga wrote:
> Iain Duncan wrote:
> 
>> I've managed to get some simple threading working with the api, but 
>> can't get csoundTableGet() to work. The app compiles but csound exits 
>> as  soon as I try to use csoundTabelGet()
>>
>> - the pointer to csound is global
>> - i try calling it from the main thread after spawning a csound 
>> thread, dies
>> - i try calling it from the yield call back routine, dies also
>>
>> If anyone can tell me what is wrong here that would be great.
> 
> 
> Beware that the yield callback may be called at a time when the table
> does not exist. Before accessing the table, use csoundTableLength to
> find out if the table exists (has length >= 1).
> Another (not related) issue is that accessing the same instance of
> Csound from multiple threads is unsafe, and you may get occasional
> crashes unless using locks around calls of Csound API functions.
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks Michael. I believe I need threads, but I'm not 100% sure. I would 
like to get the architecture to the point where we can do anything we 
want with the host app and not hiccup csound, just have the host wait a 
bit. I'd say we are on the right track if it were possible to select a 
wave file from the OS, and dynamically drop it into a csound table on 
the fly, as well as do the reverse. I realize this will be tricky 
though, and I assumed it require spawning lower priority threads to do 
the disk i/o.

Seems like there are a lot of options now, many of which are beyond me 
yet. I'll continue posting my examples for comment if people have time. 
Perhaps they can be useful eventually for a tutorial series on using the 
api.

Thanks
Iain

Michael Gogins wrote:
> First of all do you really need different threads? It may simpler for the host to call csoundCompile, then call csoundPerformKsmps and read the audio out of the spout buffer each time. In this mode, there is only one thread, the host thread, and the host drives the Csound performance. If the host buffer and the Csound buffer are different sizes, you can use 2 sets of buffer indexes and only call csoundPerformKsmps whenever spout has been consumed. This is how CsoundVST works (see CsoundVST::process()).
> 
> If you do need threads, then let Csound run in 1 thread and the host run in 1 thread. Two monitors (or mutexes) can be used to synchronize on the audio buffer. The host waits on the host monitor. Csound writes spout, releases the host monitor, and waits on the Csound monitor. The host proceeds, does whatever it is doing to consume spout, and then releases the Csound monitor and waits on the host monitor again. This causes the 2 threads to take turns producing and consuming spout.
> 
> If the host buffer and the Csound buffer are different sizes, again you can use 2 sets of indexes, one set for the host and one set for Csound. or you can copy spout into a queue and have the host copy audio out of the queue. In either case Csound will not release the host monitor until it has enqueued enough audio for the host's buffer.
> 
> The first method is simpler to write but the second method is practically as efficient since on contemporary operating systems switching threads, locking and unlocking monitors, etc., are very efficient.
> 
> Regards,
> Mike
> 
> -----Original Message-----
> From: Iain Duncan 
> Sent: Aug 20, 2005 12:54 PM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Problems with csoundTableGet()
> 
> Istvan, ( or anyone else ), would it require less in the way of 
> protection to get results out of csound using the inchannel and 
> outchannel callback routines? Or will I still be in the same boat as far 
> as getting result values from csound in other threads?
> 
> In general, what would be the recommended way of getting a given number 
> of values in and out on every kpass given a multi-threaded app?
> 
> Thanks
> iain
> 
> Istvan Varga wrote:
> 
>>Iain Duncan wrote:
>>
>>
>>>I've managed to get some simple threading working with the api, but 
>>>can't get csoundTableGet() to work. The app compiles but csound exits 
>>>as  soon as I try to use csoundTabelGet()
>>>
>>>- the pointer to csound is global
>>>- i try calling it from the main thread after spawning a csound 
>>>thread, dies
>>>- i try calling it from the yield call back routine, dies also
>>>
>>>If anyone can tell me what is wrong here that would be great.
>>
>>
>>Beware that the yield callback may be called at a time when the table
>>does not exist. Before accessing the table, use csoundTableLength to
>>find out if the table exists (has length >= 1).
>>Another (not related) issue is that accessing the same instance of
>>Csound from multiple threads is unsafe, and you may get occasional
>>crashes unless using locks around calls of Csound API functions.
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Iain Duncan wrote:

> Thanks Michael. I believe I need threads, but I'm not 100% sure. I 
> would like to get the architecture to the point where we can do 
> anything we want with the host app and not hiccup csound, just have 
> the host wait a bit. I'd say we are on the right track if it were 
> possible to select a wave file from the OS, and dynamically drop it 
> into a csound table on the fly, as well as do the reverse. I realize 
> this will be tricky though, and I assumed it require spawning lower 
> priority threads to do the disk i/o.
>
> Seems like there are a lot of options now, many of which are beyond me 
> yet. I'll continue posting my examples for comment if people have 
> time. Perhaps they can be useful eventually for a tutorial series on 
> using the api.
>
> Thanks
> Iain
>
> Michael Gogins wrote:
>
>> First of all do you really need different threads? It may simpler for 
>> the host to call csoundCompile, then call csoundPerformKsmps and read 
>> the audio out of the spout buffer each time. In this mode, there is 
>> only one thread, the host thread, and the host drives the Csound 
>> performance. If the host buffer and the Csound buffer are different 
>> sizes, you can use 2 sets of buffer indexes and only call 
>> csoundPerformKsmps whenever spout has been consumed. This is how 
>> CsoundVST works (see CsoundVST::process()).
>>
>> If you do need threads, then let Csound run in 1 thread and the host 
>> run in 1 thread. Two monitors (or mutexes) can be used to synchronize 
>> on the audio buffer. The host waits on the host monitor. Csound 
>> writes spout, releases the host monitor, and waits on the Csound 
>> monitor. The host proceeds, does whatever it is doing to consume 
>> spout, and then releases the Csound monitor and waits on the host 
>> monitor again. This causes the 2 threads to take turns producing and 
>> consuming spout.
>>
>> If the host buffer and the Csound buffer are different sizes, again 
>> you can use 2 sets of indexes, one set for the host and one set for 
>> Csound. or you can copy spout into a queue and have the host copy 
>> audio out of the queue. In either case Csound will not release the 
>> host monitor until it has enqueued enough audio for the host's buffer.
>>
>> The first method is simpler to write but the second method is 
>> practically as efficient since on contemporary operating systems 
>> switching threads, locking and unlocking monitors, etc., are very 
>> efficient.
>>
>> Regards,
>> Mike
>>
>> -----Original Message-----
>> From: Iain Duncan 
>> Sent: Aug 20, 2005 12:54 PM
>> To: csound-devel@lists.sourceforge.net
>> Subject: Re: [Cs-dev] Problems with csoundTableGet()
>>
>> Istvan, ( or anyone else ), would it require less in the way of 
>> protection to get results out of csound using the inchannel and 
>> outchannel callback routines? Or will I still be in the same boat as 
>> far as getting result values from csound in other threads?
>>
>> In general, what would be the recommended way of getting a given 
>> number of values in and out on every kpass given a multi-threaded app?
>>
>> Thanks
>> iain
>>
>> Istvan Varga wrote:
>>
>>> Iain Duncan wrote:
>>>
>>>
>>>> I've managed to get some simple threading working with the api, but 
>>>> can't get csoundTableGet() to work. The app compiles but csound 
>>>> exits as  soon as I try to use csoundTabelGet()
>>>>
>>>> - the pointer to csound is global
>>>> - i try calling it from the main thread after spawning a csound 
>>>> thread, dies
>>>> - i try calling it from the yield call back routine, dies also
>>>>
>>>> If anyone can tell me what is wrong here that would be great.
>>>
>>>
>>>
>>> Beware that the yield callback may be called at a time when the table
>>> does not exist. Before accessing the table, use csoundTableLength to
>>> find out if the table exists (has length >= 1).
>>> Another (not related) issue is that accessing the same instance of
>>> Csound from multiple threads is unsafe, and you may get occasional
>>> crashes unless using locks around calls of Csound API functions.
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>>> Practices
>>> Agile & Plan-Driven Development * Managing Projects & Teams * 
>>> Testing & QA
>>> Security * Process Improvement & Measurement * 
>>> http://www.sqe.com/bsce5sf
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>> Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
>> & QA
>> Security * Process Improvement & Measurement * 
>> http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>> Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
>> & QA
>> Security * Process Improvement & Measurement * 
>> http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
ian, what kind of an app are you attempting to build if you don't mind 
me asking?


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> ian, what kind of an app are you attempting to build if you don't mind 
> me asking?

Right now, just a framework that can be used to make user interface 
front ends for using csound in a live real time situation with multiple 
users input. I hope to come up with a design whereby csound is rock 
solid in it's own thread no matter what we do, and all user input from 
potentially multi-client user interfaces happens through their own lower 
priority threads, and is displayed likewise. So for the time being all 
I'm trying to get to happen is:

- midi comes in to portmidi module and goes on a queue
- fltk events from the mouse and keyboard come in on their own module 
and also go on the same queue
- csound controller thread takes events off the queue, parses them, and 
sends events to csound when necessary ( ie change this mixer setting, 
etc ), and spits out output display values for display threads
- fltk display and second display ( probably a simple openGL window ) is 
updated based on output control events from csound

The prototype for now will have a simple fltk window to control an lfo's 
speed and amplitude, midi cc input on the same, keyboard input on the 
same, a csd file with an lfo that takes in amp and frq and spits out 
current value along with a rising and falling sound of some kind, an 
openGL window with a bouncing ball controlled by the lfo, and feedback 
to the fltk window so that the dials move up and down if the values have 
changed via midi, and perhaps an fltk bar graph showing the lfo value at 
that point in time. My concern is to do the above in an intelligent 
manner that can later grow to accomodate potentially large operations 
while csound is running and multi user input handled by a 
server-controller thread. This will then become the multi-user front end 
for my live show sequencer/mixer/instrumet/fx rig that we use for XORNOT 
shows.

Later I would like to add the ability to have user input and display 
output with hardware modules ( rs-232 port ), OSC, and network 
connections as well.

I have a friend who just graduated from comp engineering helping me out, 
but anyone else looking for a project to help on, pipe up and perhaps we 
can start a mail list and cvs if there is interest.

Thanks
Iain




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net