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
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
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
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
Max a écrit :
true. to avoid that slow down the framerate dynamically if cpu usage is
approaching 100% in the rendering process.
or simplify the rendering processing if like me you are a fanatic of 50fps.
c
___
Pd-list@iem.at mailing list
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
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
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
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 crini...@gmx.net wrote:
Hi!
I'm currenty connecting a fft-analysis and resynthesis patch
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
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
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 +
12 matches
Mail list logo