[PD] netsend~

Nicholas Mariette nmariett at limsi.fr
Wed Sep 9 16:07:20 CEST 2009


There's a recent update here:
http://www.remu.fr/sound-delta/netsend~/?page_id=7
Nick
soundsorange.net


> did someone succeeded in making x86 pd_darwin or ppc pd_linux for
> netsend~/netreceive~ ?
> or is there something newer than http://www.nullmedium.de/dev/netsend~/  ?
>
> thank's for your help,
> fred
>
> fred-ordi wrote:
>> Sorry if this question is obvious, may be an alternate for live audio
>> processing with clusters:
>> does it exist some netsend/netreceive for audio in Puredata ?
>> I remember having using one (experimental) few years ago but was within
>> MaxMSP...
>>
>> fred
>>
>>
>> IOhannes m zmoelnig wrote:
>>> Phil Stone wrote:
>>>> Hi Hans,
>>>>
>>>> Thanks for replying.  I don't quite understand what you mean by
>>>> "manually manage".  As far as I know, without something like [pd~],
>>>> there's no way to divide up and assign the Pd audio process to more
>>>> than one core.  Half of the cores on a quad-core are therefore
>>>> useless to Pd (accounting for the fact that the graphical process
>>>> gets its own core).
>>>>
>>>
>>> the problem is, that poly-class objects are usually meant for _many_
>>> objects (10+; i'm only repeating here what hans has already said).
>>> [pd~] will fork a new thread for each of it's instances.
>>> when doing multi-core processing (and this is really the only thing
>>> pd~ is good for; e.g .it's not good if you want to have different
>>> priorities / asynchronous processing), you usually don't want to
>>> create more threads than you have cores.
>>> why? performance reasons! if you create e.g. 1000 threads for 1000
>>> instances of [doodle~] on a quad-core machine, your computer will
>>> spend more time handling context-switches and the like (that is: the
>>> overhead for managing the threads) than doing the actual job.
>>> as a rule of thumb, the optimum number of threads is about the number
>>> of cores you want to use.
>>>
>>> since what is sold to customers as "multi-core" processors usually
>>> does not involve more than 4 cores, the "best" (though probably not
>>> the most comfortable) way to assign work to the cores from within Pd
>>> is doing it "manually"
>>>
>>>
>>> fmgasdr.#
>>> IOhannes
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> _______________________________________________
> 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