OK, this sounds good!

It's in line with my own experience that synchronization overhead is quite 
low.

What I suggest is that you go ahead and do the multi-Csound, audio-mixing 
part now and get it out there. A lot of people would be interested in using 
this, especially for rendering big complex pieces off-line.

If and when you do this, be SURE to make the connections/queues between 
different instances of Csound and the mixer that blends them ABSTRACT so 
that they can be network connections. Then Csound would be clusterable. Then 
the instrument definitions could basically be as elaborate as one would 
like.

The open source ACE toolkit provides all the parts for doing these things, 
but it can be a bit challenging to understand at first...

Regards,
Mike

----- Original Message ----- 
From: "Iain Duncan" 
To: 
Sent: Saturday, April 08, 2006 6:46 AM
Subject: Re: [Cs-dev] Object design question for API use


>> OK, you had mentioned this earlier, sorry I forgot.
>>
>> However, every Csound thread you spawn will consume a small amount of
>> overhead to manage the thread. Unless you have a multiple CPU machine,
>> it is always more efficient to keep everything in a single thread.
>>
>> Have you considered using ONE Csound thread (which would also serve the
>> GUI), but use additional threads for time-consuming work? In that case:
>
> What you describe ( thanks for taking the time to do so ) is very
> similar to what I am doing. I have a csound thread and a controller
> thread which together act as the server, and then client user interface
> threads, currently just FLTK but with the aim of them also including
> input and output modules for midi, osc, serial and network connections.
> All clients send messages to the controller, the controller translates
> and dispatches messages to the csound object/thread, both data writing
> and data reading requests, and the csound thread only takes a certain
> number of messages off its queue per kpass allowing it to perform
> properly even if a lot of input is backed up in the queue ( perhaps say
> dropping an audio file into csound while it is running ). The number of
> mutexes and threads are kept low, really just one per object to protect
> its queue, and more importantly, the use of the mutexes is limited to
> the infrequently occuring input events, and one lock/unlock per kpass.
> The only time the threads use them is when queueing/dequeing messages,
> and for transport control ( obviously we need to keep a tight reign on
> how we start and stop csound, etc ). I realize that I make some
> sacrifices in efficiency to have this flexibility, but I am intending in
> the long run to have a base architecture that can be used for multi-cpu,
> multi-csound, multi-computer situations, and that will likely include
> blending of audio from seperate csound threads as well. The underlying
> purpose is to better enable group improvisation of computer music beyond
> what standalone unconnected boxes allow. So far the tests seem to be
> working well, the extra overhead of the multiple objects with queues is
> neglible compared to the audio processing ( on the order of a percent or
> two cpu use. ) This system also allows us to have displays update even
> if the data is being controlled by some other user or process.
>
> Thanks again for your input on this Michael. When I ( finally ) have
> what I think is a base architecture hashed out I will put the code up
> and would be happy to get your feedback. Mostly it's a lot of learning
> right now. ; )
>
> Iain
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> It's in line with my own experience that synchronization overhead is
> quite low.

Yeah, I just checked again, and if the display is not updating 128
knobs, the cpu diff is about 2% for me. So well worth it!

> What I suggest is that you go ahead and do the multi-Csound,
> audio-mixing part now and get it out there. A lot of people would be
> interested in using this, especially for rendering big complex pieces
> off-line.
> 
> If and when you do this, be SURE to make the connections/queues between
> different instances of Csound and the mixer that blends them ABSTRACT so
> that they can be network connections. Then Csound would be clusterable.
> Then the instrument definitions could basically be as elaborate as one
> would like.

The multi-csound part is less of a pressing concern for me than certain
other components, *but* I very much want to get the base right to enable
that. If that is something you are interested in and able to help with,
I will make the multi-csound part a higher priority. A multi-user setup
with clustering csound on multi-cpus would rock for live improvised
computer music!

May I send you my base module code for comment/criticism? As is, it is
working, but I think it would be good to add the ability to put an
arbitrary string into the message. However, I don't want to unecessarily
slow down message transfer. Perhaps the message structure should depend
on the message type? Ideally, the message structure should be flexible
enough that ALL communication between ALL modules happens as messages
send from modules to the controller and vice versa. I forsee needing a
string in there to send error messages to guis, allow sending of csd
filenamens, and use for OSC messages if necessary. At the same time,
this message will also be used to write a single audio sample in to
csound in the case of loading audio files remotely, so we want to keep
that as quick as possible.

Thanks
Iain


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net