On Fri, 2008-10-31 at 14:43 +0100, Hans Roels wrote:
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...
i wouldn't say that. i would rather say: by using blocksize 1, you make all non-accurate objectclasses more accurate. but still: [vline~] is subsample accurate and you cannot achieve that for other classes by using a blocksize of 1. also lowering the blocksize comes with more cpu costs. generally it's not recommended to do that. however, i agree, that unfortunately some things are yet not possible to do, for instance using [vline~] as the envelope generator with synched [osc~] or [phasor~].
personally, i think, that all objectclasses that deal with audio and messages at the same time should be using scheduled message and not execute the messages only on block boundaries. if this causes backwards compatibility issues, this could be achieved by adding new classes, as it happened with [vsnapshot~]. [vosc~] and [vphasor~] would be very useful. also a [vtabwrite~].
roman
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
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de