Hi,
hm, unfortunately the "switch and ramp" technique is not usable for signals started from clock-delayed messages (as in [vline~]) because [snapshot~] is too slow to react.
This actually is what I expected, but still: Does anyone have an idea, how to "declick" exponential envelope generators with arbitrary rise or fall?
I mean, how to get rid of the clicks in attached patch but still get the (sub-)-sample accurate timing of [vline~] instead of the terrible sloppiness of [ead~]?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
hello frank
i don't have a solution at hand, but a feature request (or maybe better: wishlist) for miller. i noticed by accident, that also other objects beside [vline~] and [vd~] started to work with more accuracy than one block in recent versions of pd, e.g [tabwrite~]. this is good news, but i think it is on the other hand bad to have objects, that do work only on block boundaries, where at the same time others provide sample or even subsample accuracy. it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] or [del] or the like). there are many applications one could imagine, which cannot be done or only with much effort and the use of externals yet, and which could easily be implemented in pd, if *ALL* objects, that combine signal- and message domain (objects with an signal inlet and message outlet and vice versa), would work the same (read: would have sample accuracy). it would turn pd into a more powerful application as it is now. your example explains quite well, what the benefits would be........
just my two cent
roman
On Mon, 2007-05-07 at 01:02 +0200, Frank Barknecht wrote:
Hi,
hm, unfortunately the "switch and ramp" technique is not usable for signals started from clock-delayed messages (as in [vline~]) because [snapshot~] is too slow to react.
This actually is what I expected, but still: Does anyone have an idea, how to "declick" exponential envelope generators with arbitrary rise or fall?
I mean, how to get rid of the clicks in attached patch but still get the (sub-)-sample accurate timing of [vline~] instead of the terrible sloppiness of [ead~]?
Ciao _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro]
Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements.
Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2007-05-07 at 09:40 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro]
Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements.
wow, great news again.... how did you find out about this? it is not mentioned in the release notes.
Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ...
oh, hm....... indeed, strange.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
wow, great news again.... how did you find out about this? it is not mentioned in the release notes.
Use the source, Luke: I was considereing to code my own vsnapshot~ and looked into d_ctl.c where I found, that Miller already did it. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not working as expected, though it definitely gives other results than [snapshot~]. one issue might be introduced by the rounding error of floats. the other i cannot explain. vsnapshot~ seems to pick sometimes the wrong value.
roman
On Mon, 2007-05-07 at 09:40 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro]
Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements.
Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ...
Ciao
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not working as expected, though it definitely gives other results than [snapshot~]. one issue might be introduced by the rounding error of floats. the other i cannot explain. vsnapshot~ seems to pick sometimes the wrong value.
Hm, yes, that's probably difficult to get right. Attached is my vnsapshot~ vs. vline~ patch to examine switch-and-ramp more closely.
It seems, that here's I'm a victim of the dsp tree order: the lower vline~ generating the ramp is starting a little bit too late. With the [del] object I found, that the earliest I can see a ramp not equal to 0 is about one blocksize later (1.5 msec).
Still no idea how to get around that ...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Roman Haefeli wrote:
i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not working as expected, though it definitely gives other results than [snapshot~].
i think it is working as expected but there are 2 things to bear in mind:
one issue might be introduced by the rounding error of floats. the other i cannot explain. vsnapshot~ seems to pick sometimes the wrong value.
[vline~] and [vsnapshot~] do not work exactly alike, because of this vexed causality....
when you send a message to [vline~] it is scheduled to the next dsp-block (sample accurateley); the last one is already done when you send a message to [vsnapshot~] it operates on the last dsp-block; the next one does not yet exist
this is somehow logical: when you query [vsnapshot~] you do want the result immediately (because that's the way how messages are handled in pd); the only result it can give you, is that of already known samples.
the only way to overcome this, is by delaying the sampling bang by one dsp-block.
the other thing with the "irregularities" is simpler: even when messages have "sub-sample" accuracy, the signal-vectors are only sample-accurate. so when you read the sample-values of a sawtooth immediately after the jump, you will always get different values unless the frequency of your ugen is "in sync" with your samplerate. see also: shannon's sampling theorem
attached is a modified patch
fm.asdr IOhannes
#N canvas 195 55 722 477 10; #X floatatom 12 296 0 0 0 0 - - -; #X obj 12 279 vsnapshot~; #X msg 72 206 1; #X obj 74 236 vmetro 100; #X msg 42 205 0; #X msg 13 127 bang; #X obj 13 103 loadbang; #X obj 74 255 del; #X obj 192 226 /; #X msg 192 207 64 44.1; #X floatatom 192 247 5 0 0 0 - - -; #X obj 13 226 phasor~; #X msg 70 90 44100 64; #X obj 70 113 /; #X floatatom 70 131 5 0 0 0 - - -; #X obj 13 204 f 10; #X obj 13 185 t a b; #X obj 73 184 t b a; #X msg 119 195 1000 $1; #X obj 119 212 /; #X obj 119 176 f 10; #X obj 13 156 t a a; #X obj 192 186 loadbang; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 7 0; #X connect 4 0 11 1; #X connect 5 0 21 0; #X connect 6 0 5 0; #X connect 7 0 1 0; #X connect 8 0 10 0; #X connect 9 0 8 0; #X connect 10 0 7 1; #X connect 11 0 1 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 14 0 21 0; #X connect 15 0 11 0; #X connect 16 0 15 0; #X connect 16 1 4 0; #X connect 17 0 2 0; #X connect 17 1 20 0; #X connect 18 0 19 0; #X connect 19 0 3 1; #X connect 20 0 18 0; #X connect 21 0 16 0; #X connect 21 1 17 0; #X connect 22 0 9 0;
On Mon, 2007-05-07 at 12:58 +0200, IOhannes m zmoelnig wrote:
when you send a message to [vline~] it is scheduled to the next dsp-block (sample accurateley); the last one is already done when you send a message to [vsnapshot~] it operates on the last dsp-block; the next one does not yet exist
this is somehow logical: when you query [vsnapshot~] you do want the result immediately (because that's the way how messages are handled in pd); the only result it can give you, is that of already known samples.
thanks, it seems logical for me now...
the only way to overcome this, is by delaying the sampling bang by one dsp-block.
the other thing with the "irregularities" is simpler: even when messages have "sub-sample" accuracy, the signal-vectors are only sample-accurate. so when you read the sample-values of a sawtooth immediately after the jump, you will always get different values unless the frequency of your ugen is "in sync" with your samplerate. see also: shannon's sampling theorem
ah, i see. from what i expected from [vsnapshot~] before, it should have used some kind of interpolation, that it obviously does not have. now it is also clear for me, why the discontinuousities grew with higher frequencies/smaller periods.
attached is a modified patch
what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro].
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro].
oh yes, i forgot. [vmetro] is just a [metro] replacement based on [delay] so i can use small cycles (<1ms); you can safely replace it with [metro].
mfgaösdr IOhanens
On Mon, 2007-05-07 at 16:57 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro].
oh yes, i forgot. [vmetro] is just a [metro] replacement based on [delay] so i can use small cycles (<1ms); you can safely replace it with [metro].
I've always wondered this: what does the 'v' stand for in [vline~] [vsnapshot~] etc. ..?
Jamie
two side questions:
- since computers are much faster now than in 1998, would it be
possible to change the 64 sample block timing of messages to a block~ 1 and use block~ 64 only for talking to the soundcard? 2) Is it possible to get microsecond accuracy in metro? the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference. marius.
Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro]
Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements.
Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ...
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
two side questions:
- since computers are much faster now than in 1998, would it be
possible to change the 64 sample block timing of messages to a block~ 1 and use block~ 64 only for talking to the soundcard?
Messages already are faster than [block~ 1]. It's only the conversion from messages to signals (and the other way around) that's tricky.
However doing all signal processing at [block~ 1] even today is quite a burden - and even an unnecessary one in many cases. Just try it.
- Is it possible to get microsecond accuracy in metro?
the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference.
metro handles float periods just fine. Try:
[metro 200.5] | [t b b] | | [timer] | [200.5\
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2007-05-07 at 01:02 +0200, Frank Barknecht wrote:
Hi,
hm, unfortunately the "switch and ramp" technique is not usable for signals started from clock-delayed messages (as in [vline~]) because [snapshot~] is too slow to react.
this might be old news for you guys, frank and simon, but when this technique is used on table based samplers, there is no need for a [vsnapshot~] at all. since you know the actual position of [vline~] (using timer) and the startpoint for the next cycle, you can simply look up these values with [tabread] (or [tabread4] to get some kind of a fake subsample accuracy). like this, you do not need any [snapshot~], which lacks support of 'clock-delayed' message nor any [vsnaphot~], which would require the signal to be delayed by one block, because of the signal->message-signal conversion problem (as described by IOhannes).
though, this approach might not work for synthesizers.....
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Frank Barknecht -
IOhannes m zmoelnig -
Jamie Bullock -
marius schebella -
Roman Haefeli