<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>Help unsubscribe <br>
<br>
<div class="acompli_signature">Sent from <a href="http://aka.ms/Ox5hz3">Outlook</a></div>
<br>
</div>
<br>
<br>
<br>
<div class="gmail_quote">On Tue, Sep 8, 2015 at 7:21 AM -0700, <span dir="ltr"><<a href="mailto:pd-list-request@lists.iem.at" target="_blank">pd-list-request@lists.iem.at</a>></span> wrote:<br>
<br>
</div>
<div class="BodyFragment">
<div class="PlainText">Send Pd-list mailing list submissions to<br>
pd-list@lists.iem.at<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
or, via email, send a message with subject or body 'help' to<br>
pd-list-request@lists.iem.at<br>
<br>
You can reach the person managing the list at<br>
pd-list-owner@lists.iem.at<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Pd-list digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Present and future of WebPd (Julian Brooks)<br>
2. Re: "G05.execution.order" issue (bug? just wrong?)<br>
(Alexandre Torres Porres)<br>
3. Re: "G05.execution.order" issue (bug? just wrong?) (Joe White)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 8 Sep 2015 14:23:53 +0100<br>
From: Julian Brooks <jbeezez@gmail.com><br>
To: s p <sebpiq@gmail.com><br>
Cc: Chris McCormick <chris@mccormick.cx>, "pd-list@lists.iem.at"<br>
<pd-list@lists.iem.at><br>
Subject: Re: [PD] Present and future of WebPd<br>
Message-ID:<br>
<CAGemBFQQT+swRwvqxWUtuT1fHZ2Nqsqs_SAwe-i72Xxw41hdOw@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hey Seb.<br>
<br>
Good informative post, thanks for that.<br>
<br>
It does seem you're taking the right approach to this dilemma.<br>
Think too you're being a bit hard on yourself - I wouldn't describe the<br>
list of objects implemented with native audio nodes as 'not much' at all!<br>
Quite the opposite.<br>
<br>
Conceptually, for me, it makes sense to have some separation between those<br>
native nodes that do, in effect, behave exactly like Pd vanilla objects and<br>
have a low overhead. Presumably these should be straightforward to<br>
separately maintain as a WebPd vanilla. BTW - I'm actually happy to<br>
reconceptualise/refactor some of my own patches to run on WebPd - it's ok<br>
for things to turn into something else:).<br>
<br>
And then there's those future ScriptProcessorNode possibilities that I<br>
could conceptualise as similar to PdE - something to go to when I can't<br>
find a WebPdVanilla solution.<br>
<br>
This and Jonathan's GUI rewrite are currently really interesting - this is<br>
awesome stuff you guys are up to.<br>
<br>
Regards,<br>
<br>
Julian<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 8 September 2015 at 09:46, s p <sebpiq@gmail.com> wrote:<br>
<br>
> dammit ... JavaScript bug on my website maybe?<br>
> This pure - and ugly - html version should work :<br>
> <a href="http://funktion.fm/post/present-and-future-of-webpd">http://funktion.fm/post/present-and-future-of-webpd</a><br>
><br>
> On Tue, Sep 8, 2015 at 10:42 AM, Julian Brooks <jbeezez@gmail.com> wrote:<br>
><br>
>> THis all sounds very interesting, unfortunately this:<br>
>> <a href="http://funktion.fm/#post/present-and-future-of-webpd">http://funktion.fm/#post/present-and-future-of-webpd</a><br>
>> is still devoid of text on my machine (what the deuce!:)<br>
>><br>
>> On 8 September 2015 at 07:47, s p <sebpiq@gmail.com> wrote:<br>
>><br>
>>> > When I handed WebPd over to you, one feature that was important to me<br>
>>> was to have WebPd work as a system where you could take an existing Pd<br>
>>> patch and be pretty sure it would sound and work the same<br>
>>><br>
>>> And I agreed with this goal of yours! Only if you remember, these were<br>
>>> different times. Web Audio API had not fully landed, WebPd was firefox only<br>
>>> and working on Audio Data API, which provided a simple callback to write<br>
>>> audio to the sound card buffers and nothing else, so custom dsp was the<br>
>>> only way to go. With the deprecation of Audio data API in favor of web<br>
>>> audio API, and native nodes becoming the default thing (custom dsp being<br>
>>> only a second class citizen), I couldn't just ignore the option of<br>
>>> rebuilding it on native nodes.<br>
>>><br>
>>> My hope was that :<br>
>>> 1) native nodes would be enough to implement a significant part of Pd's<br>
>>> functionalities, with ScriptProcessorNode complementing what couldn't be<br>
>>> implemented with a big !!!use these objects carefully : performance penalty<br>
>>> warning sign<br>
>>> 2) the difference in implementation in native nodes compared to pd<br>
>>> objects wouldn't be that significant.<br>
>>><br>
>>> I think I was mostly wrong on both points ... However, the biggie, which<br>
>>> decided me on this, is that you couldn't really use WebPd on mobile devices<br>
>>> with custom dsp. ScriptProcessorNode would immediately choke, and make the<br>
>>> whole thing pretty much unusable. So this was basically a choice between on<br>
>>> one hand purity and sticking to desktop Pd, on the other hand usability and<br>
>>> cross-browser / cross-device -ness. And so I chose pragmatism over purity<br>
>>> (and that was a heartbreaking choice : after my first failed attempt at<br>
>>> reimplementing WebPd with native nodes I was totally gutted :<br>
>>> <a href="https://github.com/WebAudio/web-audio-api/issues/263">https://github.com/WebAudio/web-audio-api/issues/263</a> ).<br>
>>><br>
>>> I think for now that was somehow the right choice, since I came up with<br>
>>> a version of WebPd which ... even if it parts from Pd on some points, is<br>
>>> much more useful than a faithful version which couldn't run on most<br>
>>> devices. I myself used WebPd to do things I coudn't have done before (live<br>
>>> performances on mobile phones). And I think that makes the library more<br>
>>> sustainable, since it becomes not just a fancy toy, but a serious<br>
>>> alternative to using plain Web Audio.<br>
>>><br>
>>> I woudn't reconsider that decision if it wasn't for the fact that times<br>
>>> they are a changing again, with the arrival of AudioWorker to replace<br>
>>> ScriptProcessorNode... which MIGHT make custom dsp a viable option once<br>
>>> again. So this is really all this is about. Bloody specifications changing<br>
>>> every 6 months, and me trying to keep up ;)<br>
>>><br>
>>> > I only hope to persuade you that faithfulness to Pd's output is<br>
>>> probably a feature that users will appreciate a lot.<br>
>>><br>
>>> to conclude ... you don't need to persuade me of this :) I just think it<br>
>>> is more important to have something you can use at all. But the future<br>
>>> might be brighter, and maybe these two goals won't contradict each other<br>
>>> any more.<br>
>>><br>
>>><br>
>>> On Tue, Sep 8, 2015 at 5:00 AM, Chris McCormick <chris@mccormick.cx><br>
>>> wrote:<br>
>>><br>
>>>> On 08/09/15 10:49, Chris McCormick wrote:<br>
>>>><br>
>>>>> I am glad to see it live on with<br>
>>>>> somebody who codes as energetically as you<br>
>>>>><br>
>>>><br>
>>>> chr15m: 98 commits / 8,028 ++ / 1,712 --<br>
>>>> sebpiq: 253 commits / 322,207 ++ / 250,725 --<br>
>>>><br>
>>>> Lol!<br>
>>>><br>
>>>> Chris.<br>
>>>><br>
>>>> --<br>
>>>> <a href="http://mccormick.cx/">http://mccormick.cx/</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>> *Sébastien Piquemal*<br>
>>><br>
>>> -----* @sebpiq*<br>
>>> ----- <a href="http://github.com/sebpiq">http://github.com/sebpiq</a><br>
>>> ----- <a href="http://funktion.fm">http://funktion.fm</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Pd-list@lists.iem.at mailing list<br>
>>> UNSUBSCRIBE and account-management -><br>
>>> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
>>><br>
>>><br>
>><br>
><br>
><br>
> --<br>
><br>
> *Sébastien Piquemal*<br>
><br>
> -----* @sebpiq*<br>
> ----- <a href="http://github.com/sebpiq">http://github.com/sebpiq</a><br>
> ----- <a href="http://funktion.fm">http://funktion.fm</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.puredata.info/pipermail/pd-list/attachments/20150908/61f92a62/attachment-0001.html">http://lists.puredata.info/pipermail/pd-list/attachments/20150908/61f92a62/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 8 Sep 2015 11:05:09 -0300<br>
From: Alexandre Torres Porres <porres@gmail.com><br>
To: IOhannes m zmoelnig <zmoelnig@iem.at><br>
Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at><br>
Subject: Re: [PD] "G05.execution.order" issue (bug? just wrong?)<br>
Message-ID:<br>
<CAEAsFmjKZ4eu8yjZwH_P2C=qHUiHe3CquePta4UKVPkzL6H7UA@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
wow, this is quite a technical and theoretical discussion, nice.<br>
<br>
but, keeping it simple and trying to avoid this nitty gritty completely,<br>
all I'm curious about is if I can *rely* on building a patch with order of<br>
creation/connection for both data and audio without trigger and subpatches.<br>
<br>
and by that, the question is: if i know what I'm doing in the patch in<br>
order to force the behaviour I want, and the patch is working in the way<br>
that I want because of that, and Ive saved the file and it is is now<br>
behaving the way I want every time I open it, can I *rely* that it will<br>
always open and work like that if no one edits the file changing the order<br>
of connections and everything?<br>
<br>
thanks<br>
<br>
2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig <zmoelnig@iem.at>:<br>
<br>
> On 2015-09-08 12:21, Joe White wrote:<br>
> > Technically it doesn't. You can remove and re-add an existing connection<br>
> > and it could change the order.<br>
> ><br>
> > Re-instantiating objects does the same, I assume the GUI is removing the<br>
> > object (and connection) and then re-connecting it back up.<br>
><br>
><br>
> ah yes, stupid me.<br>
><br>
> fgmasr<br>
> IOhannes<br>
><br>
> _______________________________________________<br>
> Pd-list@lists.iem.at mailing list<br>
> UNSUBSCRIBE and account-management -><br>
> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.puredata.info/pipermail/pd-list/attachments/20150908/9eb1f215/attachment-0001.html">http://lists.puredata.info/pipermail/pd-list/attachments/20150908/9eb1f215/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 8 Sep 2015 15:20:19 +0100<br>
From: Joe White <white.joe4@gmail.com><br>
To: Alexandre Torres Porres <porres@gmail.com><br>
Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at>, IOhannes m zmoelnig<br>
<zmoelnig@iem.at><br>
Subject: Re: [PD] "G05.execution.order" issue (bug? just wrong?)<br>
Message-ID:<br>
<CA+LF3Ov=XERKAw7k_YZQwBydP6hCvKi=Qs-y2Wqk7zVr-NVZoA@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Apologies for derailing the thread<br>
<br>
Ive saved the file and it is is now behaving the way I want every time I<br>
> open it, can I *rely* that it will always open and work like that if no<br>
> one edits the file changing the order of connections and everything?<br>
<br>
<br>
(As far as I know) you can be certain that a patch will run repeatedly the<br>
same way as long as no modifications to the file are made.<br>
<br>
The only caveat would be using an object like random, where its number<br>
generator state is remembered for the lifetime of the Pd application<br>
running your patch. However, if you reopen the whole application it'll be<br>
reset.<br>
<br>
On 8 September 2015 at 15:05, Alexandre Torres Porres <porres@gmail.com><br>
wrote:<br>
<br>
> wow, this is quite a technical and theoretical discussion, nice.<br>
><br>
> but, keeping it simple and trying to avoid this nitty gritty completely,<br>
> all I'm curious about is if I can *rely* on building a patch with order<br>
> of creation/connection for both data and audio without trigger and<br>
> subpatches.<br>
><br>
> and by that, the question is: if i know what I'm doing in the patch in<br>
> order to force the behaviour I want, and the patch is working in the way<br>
> that I want because of that, and Ive saved the file and it is is now<br>
> behaving the way I want every time I open it, can I *rely* that it will<br>
> always open and work like that if no one edits the file changing the order<br>
> of connections and everything?<br>
><br>
> thanks<br>
><br>
> 2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig <zmoelnig@iem.at>:<br>
><br>
>> On 2015-09-08 12:21, Joe White wrote:<br>
>> > Technically it doesn't. You can remove and re-add an existing<br>
>> connection<br>
>> > and it could change the order.<br>
>> ><br>
>> > Re-instantiating objects does the same, I assume the GUI is removing the<br>
>> > object (and connection) and then re-connecting it back up.<br>
>><br>
>><br>
>> ah yes, stupid me.<br>
>><br>
>> fgmasr<br>
>> IOhannes<br>
>><br>
>> _______________________________________________<br>
>> Pd-list@lists.iem.at mailing list<br>
>> UNSUBSCRIBE and account-management -><br>
>> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Pd-list@lists.iem.at mailing list<br>
> UNSUBSCRIBE and account-management -><br>
> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.puredata.info/pipermail/pd-list/attachments/20150908/8e700984/attachment.html">http://lists.puredata.info/pipermail/pd-list/attachments/20150908/8e700984/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Pd-list mailing list<br>
Pd-list@lists.iem.at<br>
to manage your subscription (including un-subscription) see<br>
<a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Pd-list Digest, Vol 126, Issue 26<br>
****************************************<br>
</div>
</div>
</body>
</html>