[PD] [cos~]replacement for webPd patch

s p sebpiq at gmail.com
Wed Aug 26 15:50:38 CEST 2015


Alright! I've added [until], [cos], [sin], [tan], [atan], [log], [exp],
[sqrt], [abs] to WebPd.
Please tell me if you have any problem!
Also please share your experiments when you're done ;)

On Wed, Aug 26, 2015 at 2:51 PM, Julian Brooks <jbeezez at gmail.com> wrote:

> Thanks for the info Seb - will do.
>
>
>
> On 26 August 2015 at 11:52, s p <sebpiq at gmail.com> wrote:
>
>> > since it's really easy to build [cos~] with writing [cos] values to a
>> table¹, wouldn't it make sense to add [cos] and [until] to the WebPd core?
>>
>> @IOhannes yes that's an option. Unfortunately, table lookups are not that
>> fast in Web Audio API ... and they have some bugs in firefox. In fact there
>> isn't even an object designed specifically for this. I have to use this
>> bloody WaveShaperNode (
>> http://webaudio.github.io/web-audio-api/#WaveShaperNode) and a few
>> hacks. Web Audio API is really hopeless at times.
>>
>> > is it the same situation with [abs~] and [wrap~]?
>>
>> @Julian, [abs~] would be easy, [wrap~] isn't possible with nodes once
>> again...
>>
>> > Out of curiosity how are the native nodes different from using the
>> ScriptProcessorNode?
>>
>> @Joe, I haven't made any benchmark, but from my experience the
>> performance is very very poor for ScriptProcessorNodes. I have made some
>> tests a while ago on a rather slow smartphone : while I could run several
>> dozen native BufferSourceNodes (interpolated sample playback) without any
>> problem, a single ScriptProcessorNode running a rather simple effect would
>> make the whole page choke, and lots of audio glitches ... It is no wonder
>> when you know that native nodes are optimized C++ running in a separate
>> thread, while ScriptProcessorNode is JavaScript, running in the main thread
>> of the page (which also does graphics, user events and pretty much
>> everything else)
>>
>> I am also looking forward to AudioWorkerNodes!!! But it has been a rather
>> slow process ... And then when they arrive, there will be a question, which
>> is whether it is more performant to implement the whole DSP in a single
>> AudioWorkerNode (and forget about native nodes altogether), or a mixed
>> solution which uses native nodes whenever possible and AudioWorkers when
>> not. So the future is really uncertain. For this reason I plan to
>> restructure WebPd so that it can support different distributions, with
>> different implementations or different objects. So that it would be
>> possible to choose between one or the other solution easily. Here are the
>> tasks for the next milestone 0.4.0 which I plan to finish for end of
>> September :
>> https://github.com/sebpiq/WebPd/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.4.0
>>
>> So @Julian, I'll go with the [osc] + [until] solution. Meanwhile, if you
>> don't wanna wait, you can also fill-up the table with Pd, and save the
>> table contents in the patch. Then just do table lookup as he suggested.
>>
>>
>> On Wed, Aug 26, 2015 at 12:24 PM, Joe White <white.joe4 at gmail.com> wrote:
>>
>>> I'll have to use a slow ScriptProcessorNode.
>>>
>>>
>>> Here's to hoping for Audio Worker Nodes aye :(
>>>
>>> Out of curiosity how are the native nodes different from using the
>>> ScriptProcessorNode? For something simple like abs~ or wrap~ is performance *that
>>> *drastically worse?
>>>
>>>
>>>
>>> On 26 August 2015 at 09:53, Julian Brooks <jbeezez at gmail.com> wrote:
>>>
>>>> Hi Seb,
>>>>
>>>> Thanks for having a go.
>>>> While absolutely agreeing with IOhannes, is it the same situation with
>>>> [abs~] and [wrap~]?
>>>>
>>>> Regards,
>>>>
>>>> Julian]
>>>>
>>>>
>>>>
>>>> On 26 August 2015 at 09:36, IOhannes m zmoelnig <zmoelnig at iem.at>
>>>> wrote:
>>>>
>>>>> On 2015-08-26 10:25, s p wrote:
>>>>> > Hmm ... actually I got carried away. I can't implement [cos~] or
>>>>> [env~]
>>>>> > with native web audio API nodes.
>>>>> > I'll have to use a slow ScriptProcessorNode. So if performance is
>>>>> not a
>>>>> > concern for you I'll do it, but I won't integrate it to the core of
>>>>> WebPd.
>>>>> >
>>>>>
>>>>> since it's really easy to build [cos~] with writing [cos] values to a
>>>>> table¹, wouldn't it make sense to add [cos] and [until] to the WebPd
>>>>> core?
>>>>>
>>>>>
>>>>> fgmsdt
>>>>> IOhannes
>>>>>
>>>>> ¹ assuming that table lookups in WebPd are as blindingly fast as
>>>>> anyhwere else.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> *Sébastien Piquemal*
>>
>>  -----* @sebpiq*
>>  ----- http://github.com/sebpiq
>>  ----- http://funktion.fm
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>


-- 

*Sébastien Piquemal*

 -----* @sebpiq*
 ----- http://github.com/sebpiq
 ----- http://funktion.fm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150826/8d96707a/attachment-0001.html>


More information about the Pd-list mailing list