[PD] reproduce envelope

[Hans Roels]

thanks for the clear explanation!
When I triggered a bang manually in the blocksize 1 subpatch, the 
line~ was absolutely identical. Then I tried to get rid of the 
scheduled messages in the bang from metro (by sending it to other 
objects and transforming it back to a bang) but this didn't work, I 
didn't find a hack.
Although vline is the most accurate 'in the perfect world', line and 
blocksize 1 can be more precise in the current Pd-version...

Hans r

At 18:41 30/10/2008, you wrote:
>On Thu, 2008-10-30 at 17:32 +0100, Hans Roels wrote:
> > Hello,
> >
> > Is is possible in Pd to produce exactly the same envelope again and
> > again? If I send the same message to vline and use this to cut an
> > envelope out of noise or a sine wave, it always changes a bit (if you
> > listen carefully). (The phase is always reset, that's not the
> > problem.) I recorded the sounds, had a look at the soundfiles in an
> > edit program and noticed that all the envelopes were slightly
> > different.
>
>this is actually a feature of [vline~]. [vline~] understands scheduled
>messages, which means, that messages triggered by [metro] or [delay] are
>executed by [vline~] at the exact time of the [metro]/[delay] initiated
>message. in other words: [vline~] starts ramps between audio blocks,
>even between samples. the phase setting for [osc~] is only executed on
>block boundaries. this is why you're getting inconsistent results with
>[vline~] and [osc~]
>
> > Then I used line~ in a subpatch with blocksize 1 and did
> > the same thing. This sounds better and if I looked at the recorded
> > sound files they were more identical (although the release changes a
> > bit, there seems to be a very small inaccuracy in the delay...
>
>
>[line~] on the other hand is starting the ramp always on block
>boundaries, that is why the phase reset and the ramp start at the same
>time, which is giving you consistent results. different decays might be
>the effect of rounding errors, since - in case you're not using  a
>multiple of the block size as ramp length - the resulting ramp length is
>sometimes rounded up and sometimes rounded off. (this is a only theory,
>that needs to be confirmed by someone who knows to read the c code of
>[line~]).
>
> >  but
> > you can't hear this with the sine sound. The noise sound is always a
> > bit different, I guess because it are randomly generated frequencies?).
>
>there is no phase reset for [noise~], so the results will always be
>different.
>
> > Anyway I thought that vline~ was more precise than line~ but this
> > doesn't seem to be true...?
>
>it is true, but many other objectclasses aren't. to mention only a few:
>
>- right inlet of [osc~]  and [phasor~]
>- [tabwrite~]
>- [tabplay~]
>- [writesf~]
>- [readsf~]
>probably more.
>
>all those objectclasses execute incoming message only on
>blockboundaries, which means, you get inconsistent results, when using
>them together with the indeed more accurate [vline~].
>
>roman
>
>
>
>
>___________________________________________________________
>Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de