Hi!
I'm currenty connecting a fft-analysis and resynthesis patch with a gem patch containing pix_sig2pix~ and pix_pix2sig~. I have to use separate instances of pd, so some kind of table exchange has to take place between them. my tables are 65536 samples big at the moment.
I tried netsend + until + tabread, but that was too slow and made huge drop outs in the audio patch. Then I found streamin~ and streamout~ but my patches had no sync - so I don't know beginnings and endings of successive tables.
Is there something to exchange big audio chunks or tables? I'm currently thinking about using soundfiler and a ramdisk for exchange, but if there's something more convenient I'll try that.
I found streamio13~ which can send several audio signals in parallel, so I could build a simple syncing mechanism...?
open for any suggestions...
Martin
Martin Schied wrote:
Is there something to exchange big audio chunks or tables? I'm currently thinking about using soundfiler and a ramdisk for exchange, but if there's something more convenient I'll try that.
I found streamio13~ which can send several audio signals in parallel, so I could build a simple syncing mechanism...?
open for any suggestions...
if I remember correctly then [value] is actually global, and is shared between pd instances, but the help patch is not at all clear on that and I have not used it. There have been discussions about this on the list so you could try to search. Could you use that in some way to exchange references to a table????? or to an audio file? it has a numeric value, so that could be difficult.
But as you say it may be just as easy to use a file to save/share data then pass its path/name to the other instance, e.g. via [netsend].
Simon
Simon
Simon Wise wrote:
if I remember correctly then [value] is actually global, and is shared between pd instances, but the help patch is not at all clear on that and I have not used it. There have been discussions about this on the list so you could try to search.
I tried it, it isn't like that, I am talking nonsense it seems.
Try the list archives, there has been discussion about this
Simon
Hallo,
Martin Schied hat gesagt: // Martin Schied wrote:
I'm currenty connecting a fft-analysis and resynthesis patch with a gem
patch containing pix_sig2pix~ and pix_pix2sig~. I have to use separate
instances of pd, so some kind of table exchange has to take place
between them. my tables are 65536 samples big at the moment.I tried netsend + until + tabread, but that was too slow and made huge
drop outs in the audio patch. Then I found streamin~ and streamout~ but
my patches had no sync - so I don't know beginnings and endings of
successive tables.
I've never tried it myself so far, but I've seen people like Max Neupert have great success with using the new [pd~] object (0.42) instead of running two completely separate instances of Pd for dealing with Gem vs. audio glitches, so that might be an alternative for you as well. It's easy to exchange data with a pd~ object, you just use inlet~/inlet
Ciao
Frank
GEM has pix_share objects that allow for two instances of GEM to use the same images. Would this help you with the pix_sig2pix objects sharing pix data?
On Mon, Jul 13, 2009 at 4:48 PM, Martin Schied crinimal@gmx.net wrote:
Hi!
I'm currenty connecting a fft-analysis and resynthesis patch with a gem patch containing pix_sig2pix~ and pix_pix2sig~. I have to use separate instances of pd, so some kind of table exchange has to take place between them. my tables are 65536 samples big at the moment.
I tried netsend + until + tabread, but that was too slow and made huge drop outs in the audio patch. Then I found streamin~ and streamout~ but my patches had no sync - so I don't know beginnings and endings of successive tables.
Is there something to exchange big audio chunks or tables? I'm currently thinking about using soundfiler and a ramdisk for exchange, but if there's something more convenient I'll try that.
I found streamio13~ which can send several audio signals in parallel, so I could build a simple syncing mechanism...?
open for any suggestions...
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
chris clepper wrote:
GEM has pix_share objects that allow for two instances of GEM to use the same images. Would this help you with the pix_sig2pix objects sharing pix data?
Hi! thanks for this hint. It's only pix_snap which causes glitches while reading back data from GPU. So I'm going to use pix_share and pix_snap in an other instance of pd.
@Frank: Thanks for that suggestion but I couldn't find mails in the list saying that pd~ did the job for Max Neupert. In fact his only mail I could find was about pd~ not working some time ago..?
cheers, Martin
Martin Schied a écrit :
@Frank: Thanks for that suggestion but I couldn't find mails in the list saying that pd~ did the job for Max Neupert. In fact his only mail I could find was about pd~ not working some time ago..?
pd~ did the job for me. c
cheers, Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 14.07.2009 um 21:19 schrieb Martin Schied:
@Frank: Thanks for that suggestion but I couldn't find mails in the
list saying that pd~ did the job for Max Neupert. In fact his only
mail I could find was about pd~ not working some time ago..?
it does work nicely. i think it's the way how to split audio and video
in two separate processes to avoid interference.
Max a écrit :
Am 14.07.2009 um 21:19 schrieb Martin Schied:
@Frank: Thanks for that suggestion but I couldn't find mails in the list saying that pd~ did the job for Max Neupert. In fact his only mail I could find was about pd~ not working some time ago..?
it does work nicely. i think it's the way how to split audio and video in two separate processes to avoid interference.
no, it will not avoid interference. it's the way to go if you have a dual core computer and wish do dedicated 1 core for the audio, and 1 core (+ GPU) for the images rendering. but since the 2 pd instance are synchronised at audio rate, if the video processing is using more then 100% of a CPU, then it will slow down both pd instance and you should then ear click on the audio.
to avoid interference, you should use 2 pd, and connect them via netsend.
Cyrille
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 15.07.2009 um 11:05 schrieb cyrille henry:
Max a écrit :
Am 14.07.2009 um 21:19 schrieb Martin Schied:
@Frank: Thanks for that suggestion but I couldn't find mails in
the list saying that pd~ did the job for Max Neupert. In fact his
only mail I could find was about pd~ not working some time ago..?it does work nicely. i think it's the way how to split audio and
video in two separate processes to avoid interference.no, it will not avoid interference. it's the way to go if you have a dual core computer and wish do
dedicated 1 core for the audio, and 1 core (+ GPU) for the images
rendering. but since the 2 pd instance are synchronised at audio rate, if the
video processing is using more then 100% of a CPU, then it will slow
down both pd instance and you should then ear click on the audio.
true. to avoid that slow down the framerate dynamically if cpu usage
is approaching 100% in the rendering process.
to avoid interference, you should use 2 pd, and connect them via
netsend.
that did the job but there are some difficulties with that approach:
if an instance with netserver crashes the port will be blocked for
some time.
max
Max a écrit :
that did the job but there are some difficulties with that approach: if an instance with netserver crashes the port will be blocked for some time.
i'm using vanilla pd / Gem and 2 or 3 other external on linux for many years now. everything there is very stable. crash is not an option. c
max
-
chris clepper -
cyrille henry -
Frank Barknecht -
Martin Schied -
Max -
Simon Wise