Hi Michael, I've been thinking about a networked Csound over the past few months, having a central primary host with nodes setup. There's issues with sharing global variables across the nodes, as well as ordering the data processing, but for certain scenarios it wouldn't be a problem. However, I really wanted to come up with a solution that is automatic with no restrictions and would allow rendering any normal csound piece (realtime input issues aside). I was also thinking it'd be possible to override functions at runtime in the ENVIRON struct by the host program with ones that could do syncing up of ENVIRON states between nodes as well as delegation of event processing. There might be endianness issues too. Either way, I had wanted to build a proof-of-concept idea with python where the central host would: -On startup, scan the network for nodes -Parse a CSD, do a simple splitup of the score into parts so that the density of notes per node is roughly equal -pass the environ struct to other nodes to get inital state in sync -render by calling each of the nodes, collecting input, mixing out For CSD's with no global states and pure synthesis instruments with small ftables, I think it'd be possible to create a proof-of-concept. Might be worth doing just to see what will happen! steven On 5/2/05, Michael Gogins wrote: > Multiple instances MIGHT contend for resources -- but not always! > > The most obvious example is a MIDI/audio sequencer such as Cubase, running multiple CsoundVST plugins. A number of people have asked for this. Another example would be PD or SuperCollider running multiple Csound instances. > > Yet another example would be writing a multi-threaded application based on the Csound API for rendering independent tracks of a large project on multiple threads, each using an independent instance of Csound -- "clustered Csound", if you will. > > This last scenario is exciting because it could mean scaling Csound performance up dramatically on multi-processing systems. There is no reason the API cannot be used to pull events from a common score, parcel out independent events to independent instances of Csound, collect the audio from each instance, and mix it into a common soundfile or send it to a common audio output. > > Regards, > Mike > > -----Original Message----- > From: Victor Lazzarini > Sent: May 2, 2005 11:23 AM > To: csound-devel@lists.sourceforge.net > Subject: Re: [Cs-dev] OSX changes > > Can't we move the statics into the IO dataspace we > are already using? > > Btw, if we want to run more than one csound instance in > one address space, would it mean that the several > instances would compete for IO resources? I can't > see that working on windows and OSX; if a driver is > open by one instance, another instance will not be > able to access it. We will need to have a way of sharing > these things. > > Re: merging I suggest that we merge the two and use the > pa_blocking code for windows/OSX only, and the writestream > blocking functions for Linux only. That way no new extra > command-line options are needed. > > Victor > > > > > Victor Lazzarini wrote: > > > > > pa_blocking.c already uses csound->Message(), we > > > can change rtpa.c as well, I think it's a good idea. > > > > Another issue is that rtpa.c/pa_blocking.c use static > > variables. This is not a problem as long as only one > > instance is running, but Csound5 is designed to allow > > multiple instances in the same address space (and that is > > very close to working now). > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. > > Get your fingers limbered up and give it your best shot. 4 > > great events, 4 opportunities to win big! Highest score > > wins.NEC IT Guy Games. Play to win an NEC 61 plasma > > display. Visit http://www.necitguy.com/?r=20 > > _______________________________________________ > > Csound-devel mailing list > > Csound-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net