[PD] [env~] issues

Alexandre Torres Porres porres at gmail.com
Sun Dec 14 05:52:45 CET 2014


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 at 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 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/20141214/b5fc2b87/attachment.html>


More information about the Pd-list mailing list