[PD] [cos~]replacement for webPd patch

[s p]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150826/9a3ccfe3/attachment.html>