Sure, I'd like to see your code. BTW, I doubt string processing is going to 
add any significant overhead either. When it comes to overhead, think about 
functions to call, bytes to move or access, and multiplications to do. 
Obviously in an audio synthesizer the audio processor overhead will usually 
far outstrip anything else. Doing 100 string transfers x 64 characters a 
second (or even 1000) will be small compared to doing 44,100 x 2 channels x 
8 bytes a channel transfers a second, and of course the audio 
multiplications are far beyond any string processing or GUI event processing 
(any stuff the GUI does to move pixels around is now on a separate card with 
its own memory and processor, so forget that).

Regards,
Mike

----- Original Message ----- 
From: "Iain Duncan" 
To: ; "Michael Gogins" 

Sent: Saturday, April 08, 2006 11:20 PM
Subject: Re: [Cs-dev] Object design question for API use


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