Hello everyone,

I just wanted to thank you all for developing Csound, which has become the
means through which I can realize just about any musical idea I can think
of. I recently finished Maatraameru 3, which is a program for composing with
sequences that uses the Csound API. This first work I wrote with it I
dedicated to you developers:

http://www.caseymongoven.com/catalogue/b511.htm

Casey
-- 
View this message in context: http://www.nabble.com/piece-dedicated-to-you-developers...-tf4504682.html#a12847059
Sent from the Csound - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, that was just an ideal world model ... I wasn't completely  
serious about _that solution_.

What about supplying API functions for the GEN routines then?  Let  
the end-user of the API worry about the thread problem rather than  
Csound internally... ?

greg

On Sep 25, 2007, at 2:58 PM, Steven Yi wrote:

> Hi All,
>
> Just a note I'm not keen on the instr_thread idea.  I had a chat with
> Michael Gogins the other day and explained all the issues with threads
> that currently exist and adding more possible issues is definitely not
> good.  (BTW: There are mutex opcodes already in csound; I added them
> but never documented as they are for the experimental "--num-threads="
> implementation; can find more info on that in nabble I'm sure). Using
> multiple threads already can not happen even in the naive
> implementation I wrote with num-threads due to things like curevt in
> the int CSOUND struct which goto's use to rewalk the opcode chain from
> the beginning to find a label.  (since only one event can occupy the
> curevt spot, you can see where the problem comes in when threading is
> introduced).
>
> steven
>
>
> On 9/25/07, Greg Thompson  wrote:
>> Hey guys -
>>
>> I'm working on the Csound Server for the xo and I'm trying to load  
>> audio
>> files while Csound is running (allowing the user to choose a file  
>> to load
>> and play it back).  This is okay if the file is small enough, but  
>> since I'm
>> running all of my Csound instances in one thread, if one blocks I  
>> get a
>> buffer under-run and so far ALSA is not forgiving me for this.   
>> Naturally, I
>> have a few options:
>>
>> 1 - I could run each instance of Csound in a separate thread
>>  - but I will have to do a lot of buffer sync checking which will  
>> certainly
>> add overhead ... how much .. I'm not sure ... If nothing else, it
>> complicates the code (and it still would prevent the instance from  
>> making
>> sound)
>>
>> 2 - I do have a separate thread for network events --
>>  so when I want to load an audio file - I could have it skip  
>> processing
>> (pause) in the Csound instance in my audio processing thread and  
>> load the
>> audio file in the network thread (or spawn another thread to load  
>> the file
>> so I don't block my network thread) - once its loaded, I could  
>> have it
>> un-pause
>>
>>
>> - OR -
>>
>>
>> Someone could be kind enough to devise a means of having GEN routines
>> processing in a low-priority thread.  It would be even cooler if  
>> once it
>> loaded, it could send a signal back to the caller when it  
>> finished.  Or
>> maybe someone could take it one step further and allow an entire  
>> instrument
>> to be run on a separate thread.
>>
>> ideally something like:
>>
>> instr_thread   instrument_number, priority
>>  do instr stuff
>> endin
>>
>> Worry about synchronization later ... it would be assumed that  
>> whatever
>> happens in the instrument doesn't care about synchronizing with  
>> the rest
>> anyway .. OR you add mutex opcodes or something similar   ;^}
>>
>>
>> - OR -
>>
>> Maybe there is another way that I haven't thought of ...
>>
>>
>>
>> To see how I'm currently loading the audio file.
>>
>>
>> instr 110 ; load instrument
>>
>> kCounter init 0
>>
>>
>>     Sfname      strget p4
>>
>>     Spathback       sprintf "%d/len", p5
>>     Spathbackchan sprintf "%d/channels", p5
>>     Spathbacksr     sprintf "%d/sr", p5
>>
>>
>>     ichannels filenchnls Sfname
>>     isr       filesr    Sfname
>>
>>
>>     iftno ftgen p5, 0, 0, 1, Sfname, 0, 0, 1
>>
>> if kCounter >= 0 kgoto done
>>             outvalue Spathback, ftlen(iftno)
>>             outvalue Spathbackchan, ichannels
>>             outvalue Spathbacksr, isr
>> done:
>>
>>
>> endin
>>
>>
>>
>>
>>
>>     def loadedCallback(self, message):
>>         if message.currentPath() == '/len':
>>             self._tableLength = message.argument(0)
>>         elif message.currentPath() == '/channels':
>>             self._channels = message.argument(0)
>>         elif message.currentPath() == '/sr':
>>             self._sampleRate = message.argument(0)
>>
>>
>>         if self._tableLength > 0 and self._channels > 0 and  
>> self._sampleRate
>>> 0:
>>             self.isLoaded = True
>>
>>
>>     def load(self):
>>         """
>>         Load the audio file as an f-table
>>         The instrument will notify us when the table has loaded by  
>> calling
>>         self.loadedCallback
>>         """
>>         self.loadCalled = True
>>         self.csound.registerChannel(str(self._fTableIndex),
>> self.loadedCallback)
>>
>>
>>         fEvent = 'i110 0 1 "'+self._filename+'" '+str 
>> (self._fTableIndex)
>>
>>         self.csound.playEventAsString(fEvent)
>>
>>
>> greg
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net