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 :
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.
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/
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
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.ilias@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 :
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.
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/
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
On 12/13/2014 11:14 PM, Raphaël Ilias wrote:
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
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 zmoelnig@iem.at:
On 12/13/2014 11:14 PM, Raphaël Ilias wrote:
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
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
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 zmoelnig@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
nevermind, I thought it was for feedback, but I see what it looks like now
2014-12-16 13:04 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
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 zmoelnig@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
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 <zmoelnig@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
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 zmoelnig@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
On Tuesday, December 16, 2014 8:47 AM, IOhannes m zmölnig
zmoelnig@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
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 sent this to the pd-list because i wonder if i'm the only one to feel that this issue isn't very intuitive to solve...
cheers,
Raphaël
I've only ever used this function once or twice: but if you make a subpatch with a [switch~] object inside, then you can send a bang (i think?) to that [switch~] to process just one block of signals.
Perhaps that could help here?
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.ilias@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 sent this to the pd-list because i wonder if i'm the only one to feel that this issue isn't very intuitive to solve...
cheers,
Raphaël
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
here Raphael, using [switch~]. you can do what you originally asked for. An [env~] object is put inside a subpatch, and that subpatch is explicitly forced to compute one block by banging the [switch~] object.
you can see in this example that you can change the order of execution by sending your original control bangs in different order.
On Thu, Dec 18, 2014 at 6:53 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
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:
- 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.ilias@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 sent this to the pd-list because i wonder if i'm the only one to feel that this issue isn't very intuitive to solve...
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
2014-12-18 2:46 GMT+01:00 i go bananas hard.off@gmail.com:
here Raphael, using [switch~]. you can do what you originally asked for. An [env~] object is put inside a subpatch, and that subpatch is explicitly forced to compute one block by banging the [switch~] object.
you can see in this example that you can change the order of execution by sending your original control bangs in different order.
Thank you for your suggestion.
In [env~] documentation (Miller's C.07) it is said that there is some overlapping in the inner working of RMS calculations. I wonder if switching the DSP off does mess up with overlapping (as i understand "overlapping with previous audio block").
Also, first time I see :
[t b b] | / [switch~ 1024 1 1]
I'm surprised about this "double bang", but I suppose this means "do compute one audio block and only one" (here 1024 samples).
cheers, Raphaël
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.stiltner@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
2014-12-19 5:26 GMT+01:00 i go bananas hard.off@gmail.com:
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.
yes, i tried to use your trick using only one bang, and behavior was *not always* the same (sometimes seemed not switching... however, i use the following and it works for me :
[bang~] | [del 0] | [0 ( [1 ( [ / [switch~]
clicking the [1 ( computes one block and then DSP get switched off by [bang~]
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.
yes i'm curious too... let's say i want to get the RMS amplitude of a 2048-samples "grain" of audio. if i use [env~ 2048] however i'm using a 2048-samples window length in argument, i get two RMS amplitude results spaced by 1024 samples. so i'm sitting there and wondering : am looking to the RMS amplitude of first and second half of my 2048 samples ?
Thank you Jonathan, this is very instructive !
2014-12-17 22:53 GMT+01:00 Jonathan Wilkes jancsika@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:
- 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.ilias@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 sent this to the pd-list because i wonder if i'm the only one to feel that this issue isn't very intuitive to solve...
cheers,
Raphaël
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list