<div dir="ltr">About 1) <div><br></div><div>[env~]'s help file says it's "1024 default" though, maybe it changed and miller forgot to update C07's example</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-13 20:14 GMT-02:00 Raphaël Ilias <span dir="ltr"><<a href="mailto:phae.ilias@gmail.com" target="_blank">phae.ilias@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi dear pd freaks,<br>
<br>
I'm currently using [env~] for measurement purpose (room's sound<br>
monitoring and soundfiles analysis) and I have a few questions/remarks<br>
...that unfortunately may have already been discussed here (I have<br>
been unsubscribed from the list since a couple of years).<br>
<br>
However :<br>
<br>
1)<br>
Just noticed : the [env~] help patch (from PDDP) states that default<br>
analysis window is 1024 samples, while it links to Miller's example<br>
C07.envelope.follower.pd where you can read that the default window is<br>
256 samples.<br>
<br>
<br>
2)<br>
AFAIK there is no way to dynamically (message) change the analysis<br>
window's size, at least without dynamic patching.. what I "painfully"<br>
managed to do (see attached patch "ph_env~.pd").<br>
Ah, I can see on sourceforge that it is a request open since 2012...<br>
<a href="http://sourceforge.net/p/pure-data/feature-requests/109/" target="_blank">http://sourceforge.net/p/pure-data/feature-requests/109/</a><br>
<br>
<br>
3)<br>
Last but not least, the question I can't answer myself !<br>
When using multiple [env~] it isn't very clear for me which one will<br>
output first.<br>
So it confuses me when I try to do very simple things like comparing<br>
(difference) two signals' amplitude : doing a substraction requires to<br>
input the [- ] object in correct order (right inlet before left's).<br>
While doing it the wrong order may seem to work, I realized that in<br>
fact I was comparing two different windows.<br>
The actual order of output between different [env~] seems to be<br>
related to the objects' order of creation. I think that order of<br>
creation is a trouble since you cannot "read" it in the patch, so it<br>
isn't "the diagram is the program" anymore. Moreover, as far as i can<br>
deduce from what i experimented empirically (means : i'm not sure at<br>
all) the first to output is the last that was created.<br>
My experiments with order can be found in "order_env~.pd" attached file.<br>
<br>
<br>
Finally, maybe all this mess is just me not being very clear with how<br>
message/DSP are scheluded/interfaced... but I feel that [snapshot~] is<br>
way more easy to understand and control, since it outputs value "on<br>
demand" (bang) and order can be easily stated with [trigger]. I think<br>
i'd feel much more comfortable with a kind of [env~] object that<br>
computes the enveloppe of the last N audio blocks or last N samples,<br>
"on demand", when triggered by a bang.<br>
<br>
Maybe someone will answer me that I'm really confused and that my<br>
problems are false problems... In case, I'd be glad to be taught the<br>
right way !<br>
<br>
Cheers,<br>
<br>
Raphaël<br>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div></div>