[PD] Present and future of WebPd

Julian Brooks jbeezez at gmail.com
Tue Sep 8 10:42:51 CEST 2015


THis all sounds very interesting, unfortunately this:
http://funktion.fm/#post/present-and-future-of-webpd
is still devoid of text on my machine (what the deuce!:)

On 8 September 2015 at 07:47, s p <sebpiq at gmail.com> wrote:

> > 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
>
> _______________________________________________
> 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/20150908/534ba498/attachment-0001.html>


More information about the Pd-list mailing list