[PD] Present and future of WebPd

[s p]

> When I handed WebPd over to you, one feature that was important to me was
to have WebPd work as a system where you could take an existing Pd patch
and be pretty sure it would sound and work the same

And I agreed with this goal of yours! Only if you remember, these were
different times. Web Audio API had not fully landed, WebPd was firefox only
and working on Audio Data API, which provided a simple callback to write
audio to the sound card buffers and nothing else, so custom dsp was the
only way to go. With the deprecation of Audio data API in favor of web
audio API, and native nodes becoming the default thing (custom dsp being
only a second class citizen), I couldn't just ignore the option of
rebuilding it on native nodes.

My hope was that :
1) native nodes would be enough to implement a significant part of Pd's
functionalities, with ScriptProcessorNode complementing what couldn't be
implemented with a big !!!use these objects carefully : performance penalty
warning sign
2) the difference in implementation in native nodes compared to pd objects
wouldn't be that significant.

I think I was mostly wrong on both points ... However, the biggie, which
decided me on this, is that you couldn't really use WebPd on mobile devices
with custom dsp. ScriptProcessorNode would immediately choke, and make the
whole thing pretty much unusable. So this was basically a choice between on
one hand purity and sticking to desktop Pd, on the other hand usability and
cross-browser / cross-device -ness. And so I chose pragmatism over purity
(and that was a heartbreaking choice : after my first failed attempt at
reimplementing WebPd with native nodes I was totally gutted :
https://github.com/WebAudio/web-audio-api/issues/263 ).

I think for now that was somehow the right choice, since I came up with a
version of WebPd which ... even if it parts from Pd on some points, is much
more useful than a faithful version which couldn't run on most devices. I
myself used WebPd to do things I coudn't have done before (live
performances on mobile phones). And I think that makes the library more
sustainable, since it becomes not just a fancy toy, but a serious
alternative to using plain Web Audio.

I woudn't reconsider that decision if it wasn't for the fact that times
they are a changing again, with the arrival of AudioWorker to replace
ScriptProcessorNode... which MIGHT make custom dsp a viable option once
again. So this is really all this is about. Bloody specifications changing
every 6 months, and me trying to keep up ;)

> I only hope to persuade you that faithfulness to Pd's output is probably
a feature that users will appreciate a lot.

to conclude ... you don't need to persuade me of this :) I just think it is
more important to have something you can use at all. But the future might
be brighter, and maybe these two goals won't contradict each other any
more.


On Tue, Sep 8, 2015 at 5:00 AM, Chris McCormick <chris at mccormick.cx> wrote:

> On 08/09/15 10:49, Chris McCormick wrote:
>
>> I am glad to see it live on with
>> somebody who codes as energetically as you
>>
>
> chr15m: 98 commits / 8,028 ++ / 1,712 --
> sebpiq: 253 commits / 322,207 ++ / 250,725 --
>
> Lol!
>
> Chris.
>
> --
> http://mccormick.cx/
>



-- 

*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/20150908/b9be4fe2/attachment.html>