You can write to ftables via the API (TableSet or SetTable, don't remember). Just an idea: I guess you could read an audio file with soundin in one instrument, transferring the vaules to Python vi pycalls or chn bus, then letting python write values to a csound ftable via TableSet. As kludgy as the above setup might seem, it will give you priority control of the file load operation, as you could easily divide the operation into small chunks (say, reading 100 samples off disk and writing them to an ftable) and as a result you don't have to pause csound processing to load a large file. Oeyvind 2007/9/25, Greg Thompson : > 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 > 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