[PD] Pd-list Digest, Vol 126, Issue 26
ryan legge
hamsammich at hotmail.com
Tue Sep 8 19:23:19 CEST 2015
Help unsubscribe
Sent from Outlook
On Tue, Sep 8, 2015 at 7:21 AM -0700, <pd-list-request at lists.iem.at> wrote:
Send Pd-list mailing list submissions to
pd-list at lists.iem.at
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.puredata.info/listinfo/pd-list
or, via email, send a message with subject or body 'help' to
pd-list-request at lists.iem.at
You can reach the person managing the list at
pd-list-owner at lists.iem.at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pd-list digest..."
Today's Topics:
1. Re: Present and future of WebPd (Julian Brooks)
2. Re: "G05.execution.order" issue (bug? just wrong?)
(Alexandre Torres Porres)
3. Re: "G05.execution.order" issue (bug? just wrong?) (Joe White)
----------------------------------------------------------------------
Message: 1
Date: Tue, 8 Sep 2015 14:23:53 +0100
From: Julian Brooks <jbeezez at gmail.com>
To: s p <sebpiq at gmail.com>
Cc: Chris McCormick <chris at mccormick.cx>, "pd-list at lists.iem.at"
<pd-list at lists.iem.at>
Subject: Re: [PD] Present and future of WebPd
Message-ID:
<CAGemBFQQT+swRwvqxWUtuT1fHZ2Nqsqs_SAwe-i72Xxw41hdOw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 at 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 at 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 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
>>>
>>>
>>
>
>
> --
>
> *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/61f92a62/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 8 Sep 2015 11:05:09 -0300
From: Alexandre Torres Porres <porres at gmail.com>
To: IOhannes m zmoelnig <zmoelnig at iem.at>
Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
Subject: Re: [PD] "G05.execution.order" issue (bug? just wrong?)
Message-ID:
<CAEAsFmjKZ4eu8yjZwH_P2C=qHUiHe3CquePta4UKVPkzL6H7UA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
wow, this is quite a technical and theoretical discussion, nice.
but, keeping it simple and trying to avoid this nitty gritty completely,
all I'm curious about is if I can *rely* on building a patch with order of
creation/connection for both data and audio without trigger and subpatches.
and by that, the question is: if i know what I'm doing in the patch in
order to force the behaviour I want, and the patch is working in the way
that I want because of that, and Ive saved the file and it is is now
behaving the way I want every time I open it, can I *rely* that it will
always open and work like that if no one edits the file changing the order
of connections and everything?
thanks
2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig <zmoelnig at iem.at>:
> On 2015-09-08 12:21, Joe White wrote:
> > Technically it doesn't. You can remove and re-add an existing connection
> > and it could change the order.
> >
> > Re-instantiating objects does the same, I assume the GUI is removing the
> > object (and connection) and then re-connecting it back up.
>
>
> ah yes, stupid me.
>
> fgmasr
> IOhannes
>
> _______________________________________________
> 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/9eb1f215/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 8 Sep 2015 15:20:19 +0100
From: Joe White <white.joe4 at gmail.com>
To: Alexandre Torres Porres <porres at gmail.com>
Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>, IOhannes m zmoelnig
<zmoelnig at iem.at>
Subject: Re: [PD] "G05.execution.order" issue (bug? just wrong?)
Message-ID:
<CA+LF3Ov=XERKAw7k_YZQwBydP6hCvKi=Qs-y2Wqk7zVr-NVZoA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Apologies for derailing the thread
Ive saved the file and it is is now behaving the way I want every time I
> open it, can I *rely* that it will always open and work like that if no
> one edits the file changing the order of connections and everything?
(As far as I know) you can be certain that a patch will run repeatedly the
same way as long as no modifications to the file are made.
The only caveat would be using an object like random, where its number
generator state is remembered for the lifetime of the Pd application
running your patch. However, if you reopen the whole application it'll be
reset.
On 8 September 2015 at 15:05, Alexandre Torres Porres <porres at gmail.com>
wrote:
> wow, this is quite a technical and theoretical discussion, nice.
>
> but, keeping it simple and trying to avoid this nitty gritty completely,
> all I'm curious about is if I can *rely* on building a patch with order
> of creation/connection for both data and audio without trigger and
> subpatches.
>
> and by that, the question is: if i know what I'm doing in the patch in
> order to force the behaviour I want, and the patch is working in the way
> that I want because of that, and Ive saved the file and it is is now
> behaving the way I want every time I open it, can I *rely* that it will
> always open and work like that if no one edits the file changing the order
> of connections and everything?
>
> thanks
>
> 2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig <zmoelnig at iem.at>:
>
>> On 2015-09-08 12:21, Joe White wrote:
>> > Technically it doesn't. You can remove and re-add an existing
>> connection
>> > and it could change the order.
>> >
>> > Re-instantiating objects does the same, I assume the GUI is removing the
>> > object (and connection) and then re-connecting it back up.
>>
>>
>> ah yes, stupid me.
>>
>> fgmasr
>> IOhannes
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150908/8e700984/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Pd-list mailing list
Pd-list at lists.iem.at
to manage your subscription (including un-subscription) see
http://lists.puredata.info/listinfo/pd-list
------------------------------
End of Pd-list Digest, Vol 126, Issue 26
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150908/36d97fc2/attachment-0001.html>
More information about the Pd-list
mailing list