[PD] dead links [was] Re: [PD-announce] pd 0.46-0test1 released

Julian Brooks jbeezez at gmail.com
Fri Aug 22 00:38:23 CEST 2014


On the subject of FUDI -

'http://wiki.puredata.info/en/FUDI'

Isn't up anymore (it's the solitary wikipedia external link amongst other
things).

Is there another copy/more thorough FUDI spec list somewhere?


Also, from -

"Pd Documentation chapter 4: writing Pd objects in C


Iohannes Zmoelnig has written an excellent guide to writing externs at
http://iem.kug.ac.at/pd/externals-HOWTO/ .

A paper by Theo Stojanov on the subject is at:
http://www.music.mcgill.ca/~theo/html/audio/pd_externs.pdf ."

Are currently dead links too.

IOhannes' is available here:

'iem.at/pd/externals-HOWTO/pd-externals-HOWTO.pdf'

Theo's paper is more elusive.


Regards,

Julian


On 21 August 2014 18:02, Cyrille Henry <ch at chnry.net> wrote:

>
>
> Le 21/08/2014 18:42, Miller Puckette a écrit :
>
>  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>
>> ;
>> ,
>>
>>  yes, pd~ communication is very heavy :
> 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>> listinfo/pd-list
>>
>>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140821/e6fb2267/attachment.html>


More information about the Pd-list mailing list