Le 21/08/2014 18:42, Miller Puckette a écrit :yes, pd~ communication is very heavy :
On Thu, Aug 21, 2014 at 06:06:52PM +0200, Cyrille Henry wrote:
yes, i prefer fudi to.
but on small hardware, like the one i was developing 12 years ago, OSC was faster.
not because of the reduced bandwidth, but because of the conversion between ascii character to float.
but that time is over now, and this conversion should be quicker even on "small" hardware.
cheers
c
I agree - this is still a problem for pd~, which uses FUDI. I've been thinking
for years about making a binary form of FUDI:
f <4 byte float>
s <zero-terminated character string>
;
,
sending 8 different white noise to pd~ and sending them back to pd use more than 50% cpu on a decent computer.
sending silence is much better, since their are less data to convert, but it's far from perfect.
I think having no conversion at all will not be enough optimisation.
That's why there is now a share memory external.
for audio transfer : 1 synchronisation int is needed at every audio block and it add only 1 more block delay.
since it's very efficient, the curent implementation of fudi in pd~ is no longer a problem for me.
cheers
c
One thing I keep wondering is how, in netsend/netreceive, to name this so that
it won't get confused with raw binary. Maybe it justneeds a name (BUDI?)
cheers
M
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list