p.s. Ricardo did'nt you just have a piece performed by the Ulster Orchestra using real-tme graphics rendered with GEM? am I right?
Almost right. This piece was beautifully scratched by the QUB orchestra and musicians we found all over Northern Ireland from other orchestras and music schools (about 80 + 25 choir) I used marks GEM with an nvidia card and a giant screen facing the orchestra for real-time scoring instructions. It was co-conducted by Paul Wilson who was cueing events in this part and fully conducting first movement. The initial idea was to do this remotely from our new studios using netsend~ etc. Experiments worked well because all the GEM rendering was processed in the 2nd computer and netsent~ was just transmitting midi (lots of ctlin) with no delay or interruption. Due to the fact that the piece was rehearsed and performed in the same day I took the decision to simplify technical issues and just do it on stage. Also I could not find an ethernet connection in the Concert Hall either... This, let me concentrate in important performance aspects like how the orchestra was decoding images as musical instructions and how to diffuse the overall sound in octophonic. The audio processing was done by Ian McCurdy who actually prefers hardware interaction (racks with effects and a few peaveys 1600) than max or puredata. And I used an extra G4 and msp to do 8 channel granular synthesis (key- automated) and playback some tape (all the silly work but easy to learn in a day)- My advise would be to separate in two computers real-time rendering GEM from PD audio processing even with a 1.8 Ghz, especially if the audio is very demanding (some externals are!). Also I would manipulate midi instructions remotely (using netsend/receive) and do the dsp-process in the target computer, unless you want to stream the audio from other computer via Ethernet using other objects. (Olaf Matthews can tell you more about it). Also Linux far better than NT but I did on an NT and GEM did not crashed.
I am glad to email you the score on pdf or macromedia Freehand should you like to spot ideas from it.
Ricardo
----- Original Message ----- From: "Rory Walsh" rorytheroar@yahoo.com To: pd-list@iem.kug.ac.at Sent: Tuesday, April 09, 2002 4:59 PM Subject: [PD] Pd and Gem, some questions regarding performance
I am currently working on a signal processing patch which just manages to make it through each test without crashing, however now I would like to use gem aswell and there is no way the two will work together in harmony! As soon as I turn on rendering or Audio the patch goes down, so I guess that I will use two computers, can anyone tell me the most effective way of doing this with 2 laptops for example, I presume that netsend and netreceive are the main objects but has anyone realised pieces using these methods and what are the main pitfalls I should try to avoid when programming a piece like this? Thanks in advance for the help!,
Ricardo Climent hat gesagt: // Ricardo Climent wrote:
And I used an extra G4 and msp to do 8 channel granular synthesis (key- automated) and playback some tape
How did you do that granular synthesis? Did you use GiST, the Granular Synthesis Toolkit by Gerhard Eckel and Manuel Rocha Iturbide? If yes, is this open source and where could one find it?
I'm just looking for granular synthesis stuff for PD, even if I have to write it myself, but I just don't want to start at zero...
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
Hi Rory, Ricardo,
I would not recommend to use netsend / netreceive! As I pointed out in my post concerning the 'blocking netsend', the problem is that any action that can not be executed within one dsp cycle is likely to crash Pd or at least cause interrupted audio.
I think using midi to send data from one machine to another should be saver. In my 'music for films' patch I used netreceive to get the input from the webinterface. It sometimes happened that Pd was freezing when a new socket was opened or just data transmitted. But I have to say that I also used oggcast~ and shoutcast~ externals on the same machine (which create their own sockets and cause a lot of net traffic) and was getting a total CPU load of around 80 - 95 % on a P4 1.8GHz running Win2k. As I understand it, midi is only processed / received from the input fifo when there is any time left to do so (please correct me someone in case it's completely wrong). I usually use a midi fader box to controll my Pd patches because this is much saver than using the mouse. The GUI sometimes becomes really slow making it nearly impossible to move any sliders or number boxes (or even to turn off dsp).
In general I sometimes feel that a faster machine not necessarily improves performance or stability. I have some externals that use, say, 25 % CPU on a P2 400 MHz and 20% on a P4 1.8 GHz. That's not really what one would expect (I would expect CPU usage to go down to about 8%).
Olaf
Ricardo Climent schrieb:
Also I would manipulate midi instructions remotely (using netsend/receive) and do the dsp-process in the target computer, unless you want to stream the audio from other computer via Ethernet using other objects.
hi,
just an idea -- since usually dsp is only needed at one end, how about using remote [netreceive] (or [netsend]) only at another end (e.g. GEM host), while piping (e.g. [netsend]ing via localhost, or using midi) control data into pdsend or from pdreceive program locally in the audio host? Or, even, to do the piping trick at both ends?
Krzysztof
Olaf Matthes wrote: ...
I would not recommend to use netsend / netreceive! As I pointed out in my post concerning the 'blocking netsend', the problem is that any action that can not be executed within one dsp cycle is likely to crash Pd or at least cause interrupted audio.
-----Original Message----- From: Olaf Matthes [mailto:olaf.matthes@gmx.de] Sent: 10 April 2002 12:53 To: pd-list Subject: Re: Fw: [PD] Pd and Gem, some questions regarding performance
Hi Rory, Ricardo, I would not recommend to use netsend / netreceive! As I pointed out in my post concerning the 'blocking netsend', the problem is that any action that can not be executed within one dsp cycle is likely to crash Pd or at least cause interrupted audio.
I think using midi to send data from one machine to another should be safer.
Hi Olaf. I think this is what I said!: manipulate and send midi instructions remotely (in the first computer) and do the dsp processing in the targeted computer. It worked fine to me with 16 midi channels simultaneously controlled by a ControlFreak attached to the first and passed by netsend~ to the second computer.
In my 'music for films' patch I used netreceive to get the input from the webinterface. It sometimes happened that Pd was freezing when a new socket was opened or just data transmitted. But I have to say that I also used oggcast~ and shoutcast~ externals on the same machine (which create their own sockets and cause a lot of net traffic) and was getting a total CPU load of around 80 - 95 % on a P4 1.8GHz running Win2k. As I understand it, midi is only processed / received from the input fifo when there is any time left to do so (please correct me someone in case it's completely wrong). I usually use a midi fader box to controll my Pd patches because this is much saver than using the mouse. The GUI sometimes becomes really slow making it nearly impossible to move any sliders or number boxes (or even to turn off dsp).
In general I sometimes feel that a faster machine not necessarily improves performance or stability. I have some externals that use, say, 25 % CPU on a P2 400 MHz and 20% on a P4 1.8 GHz. That's not really what one would expect (I would expect CPU usage to go down to about 8%).
Olaf
Ricardo Climent schrieb:
Also I would manipulate midi instructions remotely (using netsend/receive) and do the dsp-process in the target computer,
unless
you want to stream the audio from other computer via Ethernet using
other
objects.
Hi all,
Netsend can block, but I don't think netreceive does. Netsend's behavior seems OK on linux, W2K, or NT; I don't know about XP.
One hint would be to use the IP address and not the domain name when making connections (or, if you can figure out how to do it, hardwire the host names to teh IP addresses) so that your machine won't try to contact a name server as part of "connect".
I do want to make a threaded version of netsend someday, but I'm trying not to add things to 0.35 (just fixing bugs.)
cheers Miller
-
Frank Barknecht -
Krzysztof Czaja -
Miller Puckette -
Olaf Matthes -
Ricardo Climent -
Ricardo Climent