Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1
Feel free to comment!
Real link without facederp tracking; http://funktion.fm/#post/present-and-future-of-webpd
(actually, there is 0 text on page?)
On Mon, Sep 7, 2015 at 4:14 PM, s p sebpiq@gmail.com wrote:
Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1
Feel free to comment!
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
didn't get that Bastiaan ... is there something wrong with the link?
On Mon, Sep 7, 2015 at 4:32 PM, Bastiaan van den Berg buzz@spacedout.nl wrote:
Real link without facederp tracking; http://funktion.fm/#post/present-and-future-of-webpd
(actually, there is 0 text on page?)
On Mon, Sep 7, 2015 at 4:14 PM, s p sebpiq@gmail.com wrote:
Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1
Feel free to comment!
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yeah I had the same issue
The link takes me through facebook and then there isn't actually any content (aside from a facebook share button :D )
On 7 September 2015 at 15:36, s p sebpiq@gmail.com wrote:
didn't get that Bastiaan ... is there something wrong with the link?
On Mon, Sep 7, 2015 at 4:32 PM, Bastiaan van den Berg buzz@spacedout.nl wrote:
Real link without facederp tracking; http://funktion.fm/#post/present-and-future-of-webpd
(actually, there is 0 text on page?)
On Mon, Sep 7, 2015 at 4:14 PM, s p sebpiq@gmail.com wrote:
Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1
Feel free to comment!
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Exactly the same here
On Mon, Sep 7, 2015 at 5:31 PM, Joe White white.joe4@gmail.com wrote:
yeah I had the same issue
The link takes me through facebook and then there isn't actually any content (aside from a facebook share button :D )
On 7 September 2015 at 15:36, s p sebpiq@gmail.com wrote:
didn't get that Bastiaan ... is there something wrong with the link?
On Mon, Sep 7, 2015 at 4:32 PM, Bastiaan van den Berg buzz@spacedout.nl wrote:
Real link without facederp tracking; http://funktion.fm/#post/present-and-future-of-webpd
(actually, there is 0 text on page?)
On Mon, Sep 7, 2015 at 4:14 PM, s p sebpiq@gmail.com wrote:
Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1
Feel free to comment!
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Aaah got it ... damn facebook. So as Bastiaan said that's the real link : http://funktion.fm/#post/present-and-future-of-webpd
On Mon, Sep 7, 2015 at 6:20 PM, Bastiaan van den Berg buzz@spacedout.nl wrote:
Exactly the same here
On Mon, Sep 7, 2015 at 5:31 PM, Joe White white.joe4@gmail.com wrote:
yeah I had the same issue
The link takes me through facebook and then there isn't actually any content (aside from a facebook share button :D )
On 7 September 2015 at 15:36, s p sebpiq@gmail.com wrote:
didn't get that Bastiaan ... is there something wrong with the link?
On Mon, Sep 7, 2015 at 4:32 PM, Bastiaan van den Berg <buzz@spacedout.nl
wrote:
Real link without facederp tracking; http://funktion.fm/#post/present-and-future-of-webpd
(actually, there is 0 text on page?)
On Mon, Sep 7, 2015 at 4:14 PM, s p sebpiq@gmail.com wrote:
Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1
Feel free to comment!
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That problem can be avoided by following the netiquette, see text vs. HTML mail http://puredata.info/community/lists/Netiquette
On 2015년 09월 08일 06:33, s p wrote:
Aaah got it ... damn facebook. So as Bastiaan said that's the real link : http://funktion.fm/#post/present-and-future-of-webpd
On Mon, Sep 7, 2015 at 6:20 PM, Bastiaan van den Berg <buzz@spacedout.nl mailto:buzz@spacedout.nl> wrote:
Exactly the same here On Mon, Sep 7, 2015 at 5:31 PM, Joe White <white.joe4@gmail.com <mailto:white.joe4@gmail.com>> wrote: yeah I had the same issue The link takes me through facebook and then there isn't actually any content (aside from a facebook share button :D ) On 7 September 2015 at 15:36, s p <sebpiq@gmail.com <mailto:sebpiq@gmail.com>> wrote: didn't get that Bastiaan ... is there something wrong with the link? On Mon, Sep 7, 2015 at 4:32 PM, Bastiaan van den Berg <buzz@spacedout.nl <mailto:buzz@spacedout.nl>> wrote: Real link without facederp tracking; http://funktion.fm/#post/present-and-future-of-webpd (actually, there is 0 text on page?) On Mon, Sep 7, 2015 at 4:14 PM, s p <sebpiq@gmail.com <mailto:sebpiq@gmail.com>> wrote: Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd <http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1> Feel free to comment! -- *Sébastien Piquemal * * ** *-----*@sebpiq* -----**http://github.com/sebpiq* * ----- http://funktion.fm _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Seb,
"The first is to re-implement the whole thing with custom DSP, and forget about native nodes."
As you know, this is how the original version of WebPd was architected before you re-built it.
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 or similar when you ran it on WebPd in so far as the objects that the user used were supported. That is why I attempted to have test patches to check that the output from Pd was the same as WebPd. I understood that would incur a performance penalty, but actually several Pd patches ran ok in that initial version so performance was "acceptable" to me at the time for my use-cases.
It seems like that is not a goal you share with WebPd, rather you are making something "Pd-like". The phrase "Pure Data runtime" is probably a bit misleading for users in that context, given that you said you don't want to support objects like "cos~" out of the box and that the audio output from WebPd is different from Pd (because of using native oscillators etc.).
Obviously you have put much more work into this project and taken it further than I ever could have. I am glad to see it live on with somebody who codes as energetically as you, so thank you. I don't have any right to dictate what you do with the project, rather I only hope to persuade you that faithfulness to Pd's output is probably a feature that users will appreciate a lot.
Cheers,
Chris.
On 08/09/15 05:33, s p wrote:
Aaah got it ... damn facebook. So as Bastiaan said that's the real link : http://funktion.fm/#post/present-and-future-of-webpd
On Mon, Sep 7, 2015 at 6:20 PM, Bastiaan van den Berg <buzz@spacedout.nl mailto:buzz@spacedout.nl> wrote:
Exactly the same here On Mon, Sep 7, 2015 at 5:31 PM, Joe White <white.joe4@gmail.com <mailto:white.joe4@gmail.com>> wrote: yeah I had the same issue The link takes me through facebook and then there isn't actually any content (aside from a facebook share button :D ) On 7 September 2015 at 15:36, s p <sebpiq@gmail.com <mailto:sebpiq@gmail.com>> wrote: didn't get that Bastiaan ... is there something wrong with the link? On Mon, Sep 7, 2015 at 4:32 PM, Bastiaan van den Berg <buzz@spacedout.nl <mailto:buzz@spacedout.nl>> wrote: Real link without facederp tracking; http://funktion.fm/#post/present-and-future-of-webpd (actually, there is 0 text on page?) On Mon, Sep 7, 2015 at 4:14 PM, s p <sebpiq@gmail.com <mailto:sebpiq@gmail.com>> wrote: Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd <http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-and-future-of-webpd&h=rAQFTSiybAQFx2xobk2DeC2J2wqOfgDUiomA9I41n42NLGQ&enc=AZOXG_i02KfoVIV6XG9vq5xhJdPuL2Mq6Q1YRPu5cy-1rbI4CdJXsXrsbWSuQQe-iuSS2WQJGqJLfPVMvliJW3mh1hlKx1hxSxglu-2i5tPs9l71GFYkQJJPTEyuAvSRJgCMok4BzZSKOWjh_Ol1YFLP0ivhQjxRYm0F3yYH0DNh_Q&s=1> Feel free to comment! -- *Sébastien Piquemal * * ***-----*@sebpiq* -----**http://github.com/sebpiq* * ----- http://funktion.fm _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
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 :
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@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.
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@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 :
- 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@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.
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
dammit ... JavaScript bug on my website maybe? This pure - and ugly - html version should work : http://funktion.fm/post/present-and-future-of-webpd
On Tue, Sep 8, 2015 at 10:42 AM, Julian Brooks jbeezez@gmail.com wrote:
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@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 :
- 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@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.
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Seb.
Good informative post, thanks for that.
It does seem you're taking the right approach to this dilemma. Think too you're being a bit hard on yourself - I wouldn't describe the list of objects implemented with native audio nodes as 'not much' at all! Quite the opposite.
Conceptually, for me, it makes sense to have some separation between those native nodes that do, in effect, behave exactly like Pd vanilla objects and have a low overhead. Presumably these should be straightforward to separately maintain as a WebPd vanilla. BTW - I'm actually happy to reconceptualise/refactor some of my own patches to run on WebPd - it's ok for things to turn into something else:).
And then there's those future ScriptProcessorNode possibilities that I could conceptualise as similar to PdE - something to go to when I can't find a WebPdVanilla solution.
This and Jonathan's GUI rewrite are currently really interesting - this is awesome stuff you guys are up to.
Regards,
Julian
On 8 September 2015 at 09:46, s p sebpiq@gmail.com wrote:
dammit ... JavaScript bug on my website maybe? This pure - and ugly - html version should work : http://funktion.fm/post/present-and-future-of-webpd
On Tue, Sep 8, 2015 at 10:42 AM, Julian Brooks jbeezez@gmail.com wrote:
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@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 :
- 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@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.
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@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
Hi Seb,
On 08/09/15 14:47, s p wrote:
so I chose pragmatism over purity
That makes a lot of sense. You thought carefully about the best implementation with regards to the tradeoffs - my apologies for not seeing that.
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.
\o/
You're absolutely right that a WebPd that can run some patches without 100% sample-level accuracy is better than one which can't run on many devices at all, and your new approach sounds like a win on all platforms.
Thanks for your hard work on WebPd.
Cheers,
Chris.
@julian and @chris :)
Thanks for the thought provoking message ;)
On Wed, Sep 9, 2015 at 3:49 AM, Chris McCormick chris@mccormick.cx wrote:
Hi Seb,
On 08/09/15 14:47, s p wrote:
so I chose pragmatism over purity
That makes a lot of sense. You thought carefully about the best implementation with regards to the tradeoffs - my apologies for not seeing that.
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.
\o/
You're absolutely right that a WebPd that can run some patches without 100% sample-level accuracy is better than one which can't run on many devices at all, and your new approach sounds like a win on all platforms.
Thanks for your hard work on WebPd.
Cheers,
Chris.