If I understand your problem correctly, here's how I've done it: ... (create instance of pyro name server) ... ...(create instance of csound in a separate thread, but don't start it just yet)... ... wait for client to start... (in my case, the "client" is the gui) (python code below copied from ImproSculpt4:) print '... waiting for gui' guiConnected = 0 """Flag to signify if the GUI object is connected (via Pyro).""" while guiConnected == 0: try: gui = Pyro.core.getProxyForURI("PYRONAME://guiRemote") """ proxy for the gui object.""" guiConnected = 1 print 'gui connected' except: time.sleep(1) # now, we have a pointer to the client here in the server, # the client has a flag, signifying if it has fully loaded, # and we wait for this to happen while gui.getGuiReadyFlag() == 0: time.sleep(1) # start csound thread print 'attempting to start csound' csThread.csoundThread.start() ########## Oeyvind 2008/11/11 Chuckk Hubbard : > Hello again. > I've been working through setting this up with Pyro, and I've run into > a problem. Pyro objects on the server have to be created locally, and > AFAIK CsoundPerformanceThread(Csound) should be called after the > CppSound object is populated with orchestra, etc, exported, and > compiled. I tried subclassing both CppSound and > CsoundPerformanceThread with Pyro's remote type, and then adding a > method to create and return a CppSound attribute which is a reference > to a CsoundPerformanceThread, but the problem is that I still can't > call methods on the resulting attribute remotely. > My other thought was to create both objects on creation of the server > and change the attributes of the CppSound object by > CsoundPerformanceThread.getCsound().setCSD(csd) etc., but that doesn't > work either. > > Any suggestions as to how to go about this? > > -Chuckk > > On Sat, Nov 1, 2008 at 5:30 PM, Oeyvind Brandtsegg wrote: >> This will work well, >> and I might add that it is also possible to do the same (and more) >> using Pyro, Python Remote Objects. >> With Pyro, you can call remote methods (those residing on the >> "server") just as if they were local objects. >> >> Oeyvind >> >> 2008/11/1 victor : >>> I have the code at work. The idea is simple, nevertheless: >>> >>> 1. open a socket connection to listen to clients >>> 2. once a client connects enter a loop where the received >>> data is interpreted as python strings (using exec) >>> 3. send the python code from the client as string data >>> >>> The same idea is in the tclcsound examples in the sources, >>> but written in tcl (listener.tcl and remote-gui.tcl). I have >>> a Python version that works in similar principles. >>> >>> Victor >>> >>> >>> ----- Original Message ----- From: "Chuckk Hubbard" >>> >>> To: >>> Sent: Saturday, November 01, 2008 1:15 PM >>> Subject: [Csnd] Re: Re: Python, Csound, GUI, here's how I'm gonna do it >>> >>> >>>> I would appreciate that very much, comrade. Because I have no idea >>>> how to set up such a thing. >>>> >>>> -Chuckk >>>> >>>> On Sat, Nov 1, 2008 at 10:46 AM, victor wrote: >>>>> >>>>> Sounds good in general. What I would suggest is in additionis to use >>>>> sockets to connect between the two Python processes. In other words >>>>> have a csound 'server', then send events to it using sockets. That would >>>>> make it network-transparent as well. >>>>> >>>>> This is pretty simple to do and I have code for it, which I can send to >>>>> you, as a socialist sympathiser that I am. >>>>> >>>>> Regards >>>>> >>>>> Victor >>>>> >>>>> ----- Original Message ----- From: "Chuckk Hubbard" >>>>> >>>>> To: "Csound List" >>>>> Sent: Friday, October 31, 2008 11:59 PM >>>>> Subject: [Csnd] Python, Csound, GUI, here's how I'm gonna do it >>>>> >>>>> >>>>>> Hi. >>>>>> I've had some advice on this from various folks, one of whom is a Pure >>>>>> Data developer, and they pointed out that, as a separate process, I >>>>>> can set audio to a higher priority than the GUI. I've looked at a few >>>>>> references, and now I think this is the way to go to avoid GUI-induced >>>>>> dropouts in my Python sequencer: >>>>>> >>>>>> Import the csnd library. >>>>>> >>>>>> Run a dummy .csd whenever the user wants to query for audio devices; >>>>>> parse the output for available devices. >>>>>> >>>>>> When the user hits play(), start another instance of *python*, using >>>>>> the Csound API within it to perform a realtime score. >>>>>> >>>>>> Drop the priority (or raise the nice level, on Unix) of the parent >>>>>> process. >>>>>> >>>>>> Pipe rt line events to the audio process from the parent process. >>>>>> >>>>>> On stop(), kill the child process, like the godless Democrat I am, and >>>>>> reset the GUI's priority/nice level. >>>>>> >>>>>> The reason for using an instance of Python running the API instead of >>>>>> just starting a Csound instance for audio is twofold: I've already >>>>>> included the module in my app to query audio devices, and it's simpler >>>>>> to distribute Csound with my app as a Python module than as a separate >>>>>> executable. >>>>>> >>>>>> Does anyone have any thoughts on how well this will work? It'll be >>>>>> some work to set it up, but hopefully I can at least test the priority >>>>>> thing this weekend. I've known for a while that Pure Data works as >>>>>> several processes, one of which is basically Wish, but never quite >>>>>> understood why. And Python doesn't let one set threads to different >>>>>> priorities. >>>>>> >>>>>> -Chuckk >>>>>> >>>>>> -- >>>>>> http://www.badmuthahubbard.com >>>>>> >>>>>> >>>>>> Send bugs reports to this list. >>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe >>>>>> csound" >>>>> >>>>> >>>>> >>>>> Send bugs reports to this list. >>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe >>>>> csound" >>>>> >>>> >>>> >>>> >>>> -- >>>> http://www.badmuthahubbard.com >>>> >>>> >>>> Send bugs reports to this list. >>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe >>>> csound" >>> >>> >>> >>> Send bugs reports to this list. >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe >>> csound" >>> >> >> >> Send bugs reports to this list. >> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" >> > > > > -- > http://www.badmuthahubbard.com > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" >