Re: [PD] [env~] issues
Thank you Jonathan, this is very instructive ! 2014-12-17 22:53 GMT+01:00 Jonathan Wilkes jancs...@yahoo.com: Hi Raphaël, The problem is not very intuitive to solve. It's difficult enough to understand the flow in a patch that only uses signal objects. And it's more difficult to understand the flow in a patch that uses control objects. That's because you can no longer just assume that each object will compute its inputs before sending output-- you must instead read all the right-to-left triggering to know where the data will go. (Plus you must understanding what triggers the object chain traversal in the first place.) But it's even more difficult to understand a patch that mixes the two. And on top of _that_ you have a [delay] in the object chain, which has its own timing outside of the normal firing of control events. That normal firing of events in a chain of control objects happens in zero logical time. Oh, and the value you're providing for your delay time is zero. That isn't trivial to understand, much less come up with as a solution in the situation of [env~]. One way to approach this is to think what happens to the following patch if you turned on audio for a single block and then turn it off again: [env~] | [bang] | [delay 1000] | [print delayed] [env~] | [bang] | [print normal] The [print normal] object will obviously print before the delayed one, right? It does, but let's look at a part of how Pd schedules this stuff. It's something like this: * fire the messages from each [env~], based on the order in which were created. Let's assume the first one you created is the one connected to the [delay 1000]. Here's what happens: 1) message goes from [env~] to [bang] to [delay 1000]. The [delay 1000] schedules a bang to output 1000ms later. This next part is the key: Pd will _not_ check to see whether 1000ms has passed until it has processed step #2 below. Also important is that Pd will _immediately_ proceed to step #2 below-- it doesn't wait 1000ms before doing so. You probably already knew that part, but many programming languages do in fact have mechanisms which let you just sit there waiting before computing the next logical part of the program. 2) message goes from [env~] to [bang] to [print normal]. We get an immediate printout to the console. 3) 1000ms passes, and [delay 1000] finally sends to [print delay]. We get the second printout to the console. Now here's the (lack of) magic: if you edit your patch and replace [delay 1000] with [delay 0], the same exact process happens in the same exact order. The only difference is that Pd waits 0ms before doing step #3 instead of 1000ms. But you're still guaranteeing the same order, and the program is still following all the same steps. (In other words, [del 0] doesn't trigger any special code that I know of-- it really does schedule a delay, which just happens to be 0ms.) Finally, notice that the console printout stays the same even if you switch steps #1 and #2. In other words, the [delay] ensures that you get the printout order you want, _regardless_ of the order in which you created the [env~] objects. Also, notice that this trick doesn't scale very well. If you had a patch full of [del 0] to force ordering in the way you do above, you're almost guaranteeing that there will be bugs. Anyway, I hope everything I wrote above is correct! These things are definitely difficult to explain and understand. -Jonathan On Wednesday, December 17, 2014 2:10 PM, Raphaël Ilias phae.il...@gmail.com wrote: oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) thanks ! yes, with [delay 0] it ensures to get the good result (same block)... (also tried to get an undesired behaviour without [del 0], but didn't succeed !) i already used [delay 0] sometimes, but i don't see where it's role is documented i already knew [bang~] but with this object my doubt was always : i know that it will happen *every* block during message-domain computation, but
Re: [PD] [env~] issues
you can never really get the real response of a room because the temperature an air currents are always changeing., you can however get a very close approximation maybe. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
I'm surprised about this double bang, but I suppose this means do compute one audio block and only one (here 1024 samples). actually, i have NO idea why i needed to do the double bang. For some weird reason, a single bang was triggering the [switch~], but then the next bang did nothing. Only every second bang was triggering. So, i used [t b b] just to send 2 bangs and trigger every time. if you remove one cable from one outlet of the [t b b], you will see what i mean. not sure if there's a bug in the implementation, or what, but yeah...seems weird. I wonder if switching the DSP off does mess up with overlapping (as i understand overlapping with previous audio block). sorry, i don't actually know how the overlap is implemented, but I did some trial and error tests, sending various signals through the switched off subpatch, and through a subpatch with no [switch~] object. The outputs of each [env~] in the different subpatches seems to be the same. On Fri, Dec 19, 2014 at 12:37 PM, Billy Stiltner billy.stilt...@gmail.com wrote: you can never really get the real response of a room because the temperature an air currents are always changeing., you can however get a very close approximation maybe. ___ 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
Re: [PD] [env~] issues
Hi Raphaël, The problem is not very intuitive to solve. It's difficult enough to understand the flow in a patch that only uses signal objects. And it's more difficult to understand the flow in a patch that uses control objects. That's because you can no longer just assume that each object will compute its inputs before sending output-- you must instead read all the right-to-left triggering to know where the data will go. (Plus you must understanding what triggers the object chain traversal in the first place.) But it's even more difficult to understand a patch that mixes the two. And on top of _that_ you have a [delay] in the object chain, which has its own timing outside of the normal firing of control events. That normal firing of events in a chain of control objects happens in zero logical time. Oh, and the value you're providing for your delay time is zero. That isn't trivial to understand, much less come up with as a solution in the situation of [env~]. One way to approach this is to think what happens to the following patch if you turned on audio for a single block and then turn it off again:[env~]|[bang]|[delay 1000]|[print delayed] [env~]|[bang]|[print normal] The [print normal] object will obviously print before the delayed one, right? It does, but let's look at a part of how Pd schedules this stuff. It's something like this:* fire the messages from each [env~], based on the order in which were created. Let's assume the first one you created is the one connected to the [delay 1000]. Here's what happens:1) message goes from [env~] to [bang] to [delay 1000]. The [delay 1000] schedules a bang to output 1000ms later. This next part is the key: Pd will _not_ check to see whether 1000ms has passed until it has processed step #2 below. Also important is that Pd will _immediately_ proceed to step #2 below-- it doesn't wait 1000ms before doing so. You probably already knew that part, but many programming languages do in fact have mechanisms which let you just sit there waiting before computing the next logical part of the program.2) message goes from [env~] to [bang] to [print normal]. We get an immediate printout to the console.3) 1000ms passes, and [delay 1000] finally sends to [print delay]. We get the second printout to the console. Now here's the (lack of) magic: if you edit your patch and replace [delay 1000] with [delay 0], the same exact process happens in the same exact order. The only difference is that Pd waits 0ms before doing step #3 instead of 1000ms. But you're still guaranteeing the same order, and the program is still following all the same steps. (In other words, [del 0] doesn't trigger any special code that I know of-- it really does schedule a delay, which just happens to be 0ms.) Finally, notice that the console printout stays the same even if you switch steps #1 and #2. In other words, the [delay] ensures that you get the printout order you want, _regardless_ of the order in which you created the [env~] objects. Also, notice that this trick doesn't scale very well. If you had a patch full of [del 0] to force ordering in the way you do above, you're almost guaranteeing that there will be bugs. Anyway, I hope everything I wrote above is correct! These things are definitely difficult to explain and understand. -Jonathan On Wednesday, December 17, 2014 2:10 PM, Raphaël Ilias phae.il...@gmail.com wrote: oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) thanks ! yes, with [delay 0] it ensures to get the good result (same block)... (also tried to get an undesired behaviour without [del 0], but didn't succeed !) i already used [delay 0] sometimes, but i don't see where it's role is documented i already knew [bang~] but with this object my doubt was always : i know that it will happen *every* block during message-domain computation, but *when* in that block ? relatively to other not-triggerred objects like [env~]... well, maybe i'm going too far with this... since you gave me a working solution :-) however, also
Re: [PD] [env~] issues
seems similar to the one used to make delay line shorter than one block. and how is that trick? :) 2014-12-16 11:41 GMT-02:00 IOhannes m zmölnig zmoel...@iem.at: On 12/15/2014 11:53 PM, Raphaël Ilias wrote: Ok, I get the trick, it seems similar to the one used to make delay line shorter than one block. However, I still feel that an object give-me-RMS enveloppe-on-bang (for the last N samples or blocks) would appear to me an easier way to handle this case. If it doesn't exist, I'll try to build something like this... one day ! Many thanks ! oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) mfgadsr IOhannes ___ 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
Re: [PD] [env~] issues
That's definitely a workable solution. But if it were truly trivial then [trigger] wouldn't exist. -Jonathan On Tuesday, December 16, 2014 8:47 AM, IOhannes m zmölnig zmoel...@iem.at wrote: On 12/15/2014 11:53 PM, Raphaël Ilias wrote: Ok, I get the trick, it seems similar to the one used to make delay line shorter than one block. However, I still feel that an object give-me-RMS enveloppe-on-bang (for the last N samples or blocks) would appear to me an easier way to handle this case. If it doesn't exist, I'll try to build something like this... one day ! Many thanks ! oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) mfgadsr IOhannes ___ 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
Re: [PD] [env~] issues
On my side i would not say it is exactly trivial JmAdrien Le 16 déc. 2014 à 16:59, Jonathan Wilkes via Pd-list pd-list@lists.iem.at a écrit : That's definitely a workable solution. But if it were truly trivial then [trigger] wouldn't exist. -Jonathan On Tuesday, December 16, 2014 8:47 AM, IOhannes m zmölnig zmoel...@iem.at wrote: On 12/15/2014 11:53 PM, Raphaël Ilias wrote: Ok, I get the trick, it seems similar to the one used to make delay line shorter than one block. However, I still feel that an object give-me-RMS enveloppe-on-bang (for the last N samples or blocks) would appear to me an easier way to handle this case. If it doesn't exist, I'll try to build something like this... one day ! Many thanks ! oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) mfgadsr IOhannes ___ 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
On Tuesday, December 16, 2014 8:47 AM, IOhannes m zmölnig zmoel...@iem.at wrote: oh, but that is just trivial: Le 16 déc. 2014 à 16:59, Jonathan Wilkes via Pd-list pd-list@lists.iem.at a écrit : But if it were truly trivial then [trigger] wouldn't exist. On 12/16/2014 05:06 PM, Jma/celeonet wrote: On my side i would not say it is exactly trivial what i meant with trivial was easily solveable using well-known techniques like [trigger]. the problem itself is not trivial at all if you don't have [trigger]. fdsar IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
On 12/13/2014 11:14 PM, Raphaël Ilias wrote: 3) Last but not least, the question I can't answer myself ! When using multiple [env~] it isn't very clear for me which one will output first. [...] this sounds like the bog-standard¹ how can i force the order of execution in the signal domain question. the order of signal-object execution depends on the implicit relation-ship between objects: if object A sends data to object B, then B is guaranteed to be called after A. you can use subpatches that pass through signals to do signal order forcing. see attached patch. gfmadsr IOhannes ¹ many people do not know about it though #N canvas 1 51 782 336 10; #X obj 65 58 noise~; #X obj 65 102 -; #X floatatom 65 124 5 0 0 0 - - -, f 5; #X obj 105 80 env~; #X obj 65 79 env~; #X obj 60 194 noise~; #X obj 61 240 env~; #X obj 61 262 -; #X floatatom 61 284 5 0 0 0 - - -, f 5; #N canvas 1 51 450 300 calc 0; #X obj 59 22 inlet~; #X obj 159 74 env~; #X obj 159 96 outlet; #X obj 59 134 outlet~; #X connect 0 0 1 0; #X connect 0 0 3 0; #X connect 1 0 2 0; #X restore 61 218 pd calc first; #X text 37 160 force right-hand [env~] to be calculated before left-hand [env~]; #X text 63 17 oops \, out of order: left-hand [env~] gets called before right-hand [env~] leading to a block-delay; #X connect 0 0 3 0; #X connect 0 0 4 0; #X connect 1 0 2 0; #X connect 3 0 1 1; #X connect 4 0 1 0; #X connect 5 0 9 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 9 0 6 0; #X connect 9 1 7 1; signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
Ok, I get the trick, it seems similar to the one used to make delay line shorter than one block. However, I still feel that an object give-me-RMS enveloppe-on-bang (for the last N samples or blocks) would appear to me an easier way to handle this case. If it doesn't exist, I'll try to build something like this... one day ! Many thanks ! Raphaël 2014-12-15 20:40 GMT+01:00 IOhannes m zmölnig zmoel...@iem.at: On 12/13/2014 11:14 PM, Raphaël Ilias wrote: 3) Last but not least, the question I can't answer myself ! When using multiple [env~] it isn't very clear for me which one will output first. [...] this sounds like the bog-standard¹ how can i force the order of execution in the signal domain question. the order of signal-object execution depends on the implicit relation-ship between objects: if object A sends data to object B, then B is guaranteed to be called after A. you can use subpatches that pass through signals to do signal order forcing. see attached patch. gfmadsr IOhannes ¹ many people do not know about it though ___ 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
[PD] [env~] issues
Hi dear pd freaks, I'm currently using [env~] for measurement purpose (room's sound monitoring and soundfiles analysis) and I have a few questions/remarks ...that unfortunately may have already been discussed here (I have been unsubscribed from the list since a couple of years). However : 1) Just noticed : the [env~] help patch (from PDDP) states that default analysis window is 1024 samples, while it links to Miller's example C07.envelope.follower.pd where you can read that the default window is 256 samples. 2) AFAIK there is no way to dynamically (message) change the analysis window's size, at least without dynamic patching.. what I painfully managed to do (see attached patch ph_env~.pd). Ah, I can see on sourceforge that it is a request open since 2012... http://sourceforge.net/p/pure-data/feature-requests/109/ 3) Last but not least, the question I can't answer myself ! When using multiple [env~] it isn't very clear for me which one will output first. So it confuses me when I try to do very simple things like comparing (difference) two signals' amplitude : doing a substraction requires to input the [- ] object in correct order (right inlet before left's). While doing it the wrong order may seem to work, I realized that in fact I was comparing two different windows. The actual order of output between different [env~] seems to be related to the objects' order of creation. I think that order of creation is a trouble since you cannot read it in the patch, so it isn't the diagram is the program anymore. Moreover, as far as i can deduce from what i experimented empirically (means : i'm not sure at all) the first to output is the last that was created. My experiments with order can be found in order_env~.pd attached file. Finally, maybe all this mess is just me not being very clear with how message/DSP are scheluded/interfaced... but I feel that [snapshot~] is way more easy to understand and control, since it outputs value on demand (bang) and order can be easily stated with [trigger]. I think i'd feel much more comfortable with a kind of [env~] object that computes the enveloppe of the last N audio blocks or last N samples, on demand, when triggered by a bang. Maybe someone will answer me that I'm really confused and that my problems are false problems... In case, I'd be glad to be taught the right way ! Cheers, Raphaël #N canvas 615 105 585 462 10; #X obj 88 45 inlet~; #N canvas 622 239 464 328 \$0-guts 0; #X obj 10 10 inlet~; #X obj 10 30 env~ 1024; #X obj 10 50 outlet; #X connect 0 0 1 0; #X connect 1 0 2 0; #X restore 87 98 pd \$0-guts; #X obj 87 140 outlet; #X obj 302 182 s pd-\$0-guts; #X msg 302 139 clear \, obj 10 10 inlet~ \, obj 10 30 env~ \$1 \, obj 10 50 outlet \, connect 0 0 1 0 \, connect 1 0 2 0; #X obj 275 281 iemguts/sendcanvas; #X obj 275 35 inlet; #X msg 275 249 connect 0 0 1 0 \, connect 1 0 2 0; #X obj 275 111 t b f; #X obj 275 217 delay 0; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 4 0 3 0; #X connect 6 0 8 0; #X connect 7 0 5 0; #X connect 8 0 9 0; #X connect 8 1 4 0; #X connect 9 0 7 0; #N canvas 483 87 514 527 10; #X obj 72 197 ph_env~; #X msg 175 127 1024; #X obj 72 144 noise~; #X obj 72 304 t b b; #X obj 72 351 timer; #X obj 72 390 nbx 5 14 -1e+037 1e+037 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 10.6667 256; #X msg 223 127 2048; #X msg 266 127 4096; #X obj 244 323 samplerate~; #X obj 217 297 t f b; #X obj 217 275 / 2; #X obj 217 342 /; #X obj 217 366 * 1000; #X obj 217 390 nbx 5 14 -1e+037 1e+037 0 0 empty empty empty 10 -8 0 10 -262144 -1 -1 10.6667 256; #X obj 175 180 t f; #X obj 101 244 nbx 5 14 -1e+037 1e+037 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 95.4811 256; #X text 173 99 dynamically change window; #X text -22 420 OUTPUT rate; #X text 70 419 measured; #X text 220 419 theoric; #X text -28 46 an abstraction (a trick using dynamic patching) to change the size of the analysis window of an [env~] objet; #X connect 0 0 3 0; #X connect 0 0 15 0; #X connect 1 0 14 0; #X connect 2 0 0 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 5 0; #X connect 6 0 14 0; #X connect 7 0 14 0; #X connect 8 0 11 1; #X connect 9 0 11 0; #X connect 9 1 8 0; #X connect 10 0 9 0; #X connect 11 0 12 0; #X connect 12 0 13 0; #X connect 14 0 0 1; #X connect 14 0 10 0; #N canvas -1624 -205 926 882 10; #X obj 343 186 -; #X obj 336 20 noise~; #X obj 341 234 nbx 5 14 -1e+037 1e+037 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 0 256; #X obj 30 184 -; #X obj 23 18 noise~; #X obj 29 232 nbx 5 14 -1e+037 1e+037 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 -0.0153732 256; #X obj 78 554 -; #X obj 71 388 noise~; #X obj 78 589 nbx 5 14 -1e+037 1e+037 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 0 256; #X obj 114 522 t b f; #X obj 88 709 timer; #X obj 85 684 t b b; #X obj 85 660 t b f; #X obj 89 733 pack f f; #X obj 106 1642 -; #X obj 205 1600 f; #X obj 250 1599 f; #X obj 206 1554 t b b; #X obj 221 1646 -; #X obj 123 864 noise~; #X obj 102 995 timer; #X obj 103 968 t b; #X obj
Re: [PD] [env~] issues
About 1) [env~]'s help file says it's 1024 default though, maybe it changed and miller forgot to update C07's example 2014-12-13 20:14 GMT-02:00 Raphaël Ilias phae.il...@gmail.com: Hi dear pd freaks, I'm currently using [env~] for measurement purpose (room's sound monitoring and soundfiles analysis) and I have a few questions/remarks ...that unfortunately may have already been discussed here (I have been unsubscribed from the list since a couple of years). However : 1) Just noticed : the [env~] help patch (from PDDP) states that default analysis window is 1024 samples, while it links to Miller's example C07.envelope.follower.pd where you can read that the default window is 256 samples. 2) AFAIK there is no way to dynamically (message) change the analysis window's size, at least without dynamic patching.. what I painfully managed to do (see attached patch ph_env~.pd). Ah, I can see on sourceforge that it is a request open since 2012... http://sourceforge.net/p/pure-data/feature-requests/109/ 3) Last but not least, the question I can't answer myself ! When using multiple [env~] it isn't very clear for me which one will output first. So it confuses me when I try to do very simple things like comparing (difference) two signals' amplitude : doing a substraction requires to input the [- ] object in correct order (right inlet before left's). While doing it the wrong order may seem to work, I realized that in fact I was comparing two different windows. The actual order of output between different [env~] seems to be related to the objects' order of creation. I think that order of creation is a trouble since you cannot read it in the patch, so it isn't the diagram is the program anymore. Moreover, as far as i can deduce from what i experimented empirically (means : i'm not sure at all) the first to output is the last that was created. My experiments with order can be found in order_env~.pd attached file. Finally, maybe all this mess is just me not being very clear with how message/DSP are scheluded/interfaced... but I feel that [snapshot~] is way more easy to understand and control, since it outputs value on demand (bang) and order can be easily stated with [trigger]. I think i'd feel much more comfortable with a kind of [env~] object that computes the enveloppe of the last N audio blocks or last N samples, on demand, when triggered by a bang. Maybe someone will answer me that I'm really confused and that my problems are false problems... In case, I'd be glad to be taught the right way ! Cheers, Raphaël ___ 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
