On 6/2/06, Arie van Schutterhoef arsche@xs4all.nl wrote:
about having the dsp running on seperate cpu's simultanously http://music.york.ac.uk/rimm/tech.htm
It would be possible for Pd to use the same Unix shm (and the Win32 equivalent) but some sort of sync system would probably be needed to keep the buffers moving along and not outputting duplicate or partial DSP frames. I put a very non-sync shm object in GEM which works fine for video as that is more forgiving of minor problems compared to audio.
Jack is another possiblity to spread DSP over multiple processes. It might be possible for Pd to open several processes and manage them using one patcher although I have no idea about that feasibility.
On Fri, 2006-06-02 at 20:37 -0500, chris clepper wrote:
Jack is another possiblity to spread DSP over multiple processes. It might be possible for Pd to open several processes and manage them using one patcher although I have no idea about that feasibility.
jack spreads the dsp graph to several processes, but schedules the processes in a row ... jackdmp by grame is able to schedule processes in parallel, though ...
tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs
On Jun 3, 2006, at 3:37 AM, chris clepper wrote:
On 6/2/06, Arie van Schutterhoef arsche@xs4all.nl wrote:
about having the dsp running on seperate cpu's simultanously http://music.york.ac.uk/rimm/tech.htm
It would be possible for Pd to use the same Unix shm (and the Win32
equivalent) but some sort of sync system would probably be needed
to keep the buffers moving along and not outputting duplicate or
partial DSP frames. I put a very non-sync shm object in GEM which
works fine for video as that is more forgiving of minor problems
compared to audio.Jack is another possiblity to spread DSP over multiple processes.
It might be possible for Pd to open several processes and manage
them using one patcher although I have no idea about that feasibility.
Its quite easy to spread the calculation of multiple voices across
CPUs. My brother and I did this for this sound installation:
We used 6 computers each running the same patch all controlled by a
master patch. If you used something like OSC timetagging, which
AFAIK doesn't exist in any OSC implementations, then you could
actually have pretty tight sync, and perhaps decent latency,
depending on your network setup.
.hc
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism."
- retired U.S. Army general,
William Odom
On Sat, 2006-06-03 at 14:32 +0200, Hans-Christoph Steiner wrote:
On Jun 3, 2006, at 3:37 AM, chris clepper wrote:
On 6/2/06, Arie van Schutterhoef arsche@xs4all.nl wrote: >about having the dsp running on seperate cpu's simultanously >http://music.york.ac.uk/rimm/tech.htm
It would be possible for Pd to use the same Unix shm (and the Win32 equivalent) but some sort of sync system would probably be needed to keep the buffers moving along and not outputting duplicate or partial DSP frames. I put a very non-sync shm object in GEM which works fine for video as that is more forgiving of minor problems compared to audio.
Jack is another possiblity to spread DSP over multiple processes. It might be possible for Pd to open several processes and manage them using one patcher although I have no idea about that feasibility.
Its quite easy to spread the calculation of multiple voices across CPUs. My brother and I did this for this sound installation:
We used 6 computers each running the same patch all controlled by a master patch. If you used something like OSC timetagging, which AFAIK doesn't exist in any OSC implementations, then you could actually have pretty tight sync, and perhaps decent latency, depending on your network setup.
when you used 6 computers, i guess, each computer had his own audio interface ... there are differences between 6 computers and one computer with 6 cpus ... one car with 6 engines is something different than 6 cars :)
tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs
We used 6 computers each running the same patch all controlled by a master patch. If you used something like OSC timetagging, which AFAIK doesn't exist in any OSC implementations, then you could actually have pretty tight sync, and perhaps decent latency, depending on your network setup.
when you used 6 computers, i guess, each computer had his own audio interface ... there are differences between 6 computers and one computer with 6 cpus ... one car with 6 engines is something different than 6 cars :)
Remembering my truck driving lessons, i know that it's possible to have two drivers in a car. Consequently it is also possible to have two instances of PD on the same machine outputting to the same audio interface (or different channels of it), most probably using CPU time on one of the dual cores each. I wouldn't say that this is a perfect, easy-to-sync solution, though....
greetings, Thomas
On Jun 3, 2006, at 5:18 PM, Thomas Grill wrote:
We used 6 computers each running the same patch all controlled by a master patch. If you used something like OSC timetagging, which
AFAIK doesn't exist in any OSC implementations, then you could actually
have pretty tight sync, and perhaps decent latency, depending on your network setup.when you used 6 computers, i guess, each computer had his own audio interface ... there are differences between 6 computers and one
computer with 6 cpus ... one car with 6 engines is something different than 6 cars :)Remembering my truck driving lessons, i know that it's possible to
have two drivers in a car. Consequently it is also possible to have two instances of PD on the
same machine outputting to the same audio interface (or different
channels of it), most probably using CPU time on one of the dual
cores each. I wouldn't say that this is a perfect, easy-to-sync
solution, though....
Sounds like the next step is to write software for clustering Pd!
That would be a nice way to get a lot of audio processing on many
channels: one computer per channel. Sounds like a project for IEM...
.hc
"Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies."
- Amy Smith
-
chris clepper -
Hans-Christoph Steiner -
Thomas Grill -
Tim Blechmann