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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list