[PD] problem using [udpsend] from iemnet (or mrpeach) in a sub-process (with [pd~])

Bernardo Barros bernardobarros2 at gmail.com
Fri Aug 20 19:05:26 CEST 2010

Hi Johannes!

Hum, I used csound/supercollider terminology here. Audio rate is
sample precision, control rate is one value per block, right?
He needs 20000 floating-points values per second, I can only think of
audio signals for this.

Well, if he start pd with "pd -jack" and make three more channels he
can connect these extra channels from puredata:0 as input to
puredata:1 in JACK, right? (QJackCtl or Patchage would make it very

I did not know JACK could deal with values outside the -1/+1 range.

2010/8/20 IOhannes m zmölnig <zmoelnig at iem.at>:
> Hash: SHA1
> On 08/20/2010 04:58 PM, Bernardo Barros wrote:
>> maybe as audio signal through JACK? That is the fastest way I'm aware.
>> That would be 441000 values per second per channel -1.0/+1.0, then you
>> had to rescale again.
> is that true.
> jack internally uses floating point samples, so i don't see a reason why
> jack should not be able to transmit samples outside the [-1..+1] range.
> apart from that, you won't be able to use jack from within [pd~], as the
> [dac~]s in [pd~] are mapped to the outlet~s of the object (that is: the
> inner pd cannot connect to the audio api directly)
> if course you could just use 2 separate Pd's anyhow, in which case jack
> would work.
> an even faster way to transport would be Gem's shared memory objects
> (see [pix_share_read]).
> however it's probably not so fast to convert the data to/from the pix
> format.
> fgmasdr
> IOhannes
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> iEYEARECAAYFAkxusKEACgkQkX2Xpv6ydvSEdwCghiXF587vWRRZ95fIZud414Qj
> xs0An2077wpG2lonhA59im5OyDWJrA6n
> =e910
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list