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