[PD] [cos~]replacement for webPd patch

[Julian Brooks]

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