Hi, I am trying to implement the switch ramp that the list was talking about. Attached you will find the abstraction and a patch showing the bug.
Why doesn't this work? Actually, it kind of works, but there is an annoying glitch (when you replace the lines with vlines inside mix.switch.ramp~ the clicking is even worse).
Tom
On Tue, 2007-10-02 at 13:52 -0400, Thomas O Fredericks wrote:
Hi, I am trying to implement the switch ramp that the list was talking about. Attached you will find the abstraction and a patch showing the bug.
hm, your buggy patc sounds right to me, though i see the deformation in the array. this isn't actually bad at all. the deformation comes from the ramp you are adding, though it's not quite hearable. even more, when you use that technique in a reallife example, the deformation is not bad, but wanted. in your example, you apply it on a constant sinewave, which wouldn't be something, that you would do in a patch. so: do not mind about the deformation, since it is what you actually want.
Why doesn't this work?
it does, doesn't it?
Actually, it kind of works, but there is an annoying glitch (when you replace the lines with vlines inside mix.switch.ramp~ the clicking is even worse).
[line~] and [vline~] are _not_ interchangeable. since [vline~] uses sort of time tagged messages, it will start the ramp somewhere between block boundaries, if it is triggered by [delay] or [metro] -> this produces the clicks. check the corresponding thread 'switch and ramp' in the pd-list for detailed reasons, why it isn't possible to implement that technique with [vline~]
roman
___________________________________________________________ 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:
On Tue, 2007-10-02 at 13:52 -0400, Thomas O Fredericks wrote:
Actually, it kind of works, but there is an annoying glitch (when you replace the lines with vlines inside mix.switch.ramp~ the clicking is even worse).
[line~] and [vline~] are _not_ interchangeable. since [vline~] uses sort of time tagged messages, it will start the ramp somewhere between block boundaries, if it is triggered by [delay] or [metro] -> this produces the clicks. check the corresponding thread 'switch and ramp' in the pd-list for detailed reasons, why it isn't possible to implement that technique with [vline~]
Well, it's a bit more complicated than that ... or simpler, depending on what you want to do. It's easy to make Tom's patch work with vline~: You just need to use [vsnapshot~] as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
vsnapshot~? Where can I find it's help? (I use Ubuntu PD(not extended) and PD 0.40-2)
I still see inconsistencies in the patch I submitted I will try to make something a little clearer: please try the new attached patches and tell me why the little bit before the ramp changes size (I suspect that is the size of one block, sometimes there, sometimes not). How can I make this consistent?
Tom
On 10/3/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Tue, 2007-10-02 at 13:52 -0400, Thomas O Fredericks wrote:
Actually, it kind of works, but there is an annoying glitch (when you replace the lines with vlines inside mix.switch.ramp~ the clicking is even worse).
[line~] and [vline~] are _not_ interchangeable. since [vline~] uses sort of time tagged messages, it will start the ramp somewhere between block boundaries, if it is triggered by [delay] or [metro] -> this produces the clicks. check the corresponding thread 'switch and ramp' in the pd-list for detailed reasons, why it isn't possible to implement that technique with [vline~]
Well, it's a bit more complicated than that ... or simpler, depending on what you want to do. It's easy to make Tom's patch work with vline~: You just need to use [vsnapshot~] as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Are there any objects to make ramps smaller than one second?
Tom
On 10/3/07, Thomas O Fredericks tof@danslchamp.org wrote:
vsnapshot~? Where can I find it's help? (I use Ubuntu PD(not extended) and PD 0.40-2)
I still see inconsistencies in the patch I submitted I will try to make something a little clearer: please try the new attached patches and tell me why the little bit before the ramp changes size (I suspect that is the size of one block, sometimes there, sometimes not). How can I make this consistent?
Tom
On 10/3/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Tue, 2007-10-02 at 13:52 -0400, Thomas O Fredericks wrote:
Actually, it kind of works, but there is an annoying glitch (when
you
replace the lines with vlines inside mix.switch.ramp~ the clicking
is
even worse).
[line~] and [vline~] are _not_ interchangeable. since [vline~] uses
sort
of time tagged messages, it will start the ramp somewhere between
block
boundaries, if it is triggered by [delay] or [metro] -> this produces the clicks. check the corresponding thread 'switch and ramp' in the pd-list for detailed reasons, why it isn't possible to implement that technique with [vline~]
Well, it's a bit more complicated than that ... or simpler, depending on what you want to do. It's easy to make Tom's patch work with vline~: You just need to use [vsnapshot~] as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2007-10-03 at 09:30 -0400, Thomas O Fredericks wrote:
Are there any objects to make ramps smaller than one second?
you mean smaller than one millisecond?
[vline~] can do it for sure.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 2007-10-03 at 09:26 -0400, Thomas O Fredericks wrote:
vsnapshot~? Where can I find it's help? (I use Ubuntu PD(not extended) and PD 0.40-2)
there is no help-file for [vsnapshot~] yet, afaik. but the way it works could probably be derived from the name, respectively from the 'v' in its name. as [vline~] it uses timetagged messages, so that it doesn't only make a snapshot of samples on the block boundaries, but of a sample somewhere in between (depending on the time tag). *) beware that the result will output one block later and this is also the reason, why it's not possible to use [vsnapshot~] in combination with [vline~] to implement the 'switch and ramp' technique (you would need to delay the second signal by one block).
*) i am not sure how it is actually implemented and whether it uses a time tag or whatsoever, but for me it is a sufficient explanation for how these objects work.
I still see inconsistencies in the patch I submitted I will try to make something a little clearer: please try the new attached patches and tell me why the little bit before the ramp changes size (I suspect that is the size of one block, sometimes there, sometimes not). How can I make this consistent?
ther reason here is that you use the direct output of [metro] to trigger [tabwrite~] and the [line~] in [mix.switch.ramp~] is triggered exactly 5ms later (because of the [del 5]). the problem is, that [tabwrite~] as well as [line~] execute only on block boundaries. since they are 5ms apart from each other and 5ms is not a multiple of the blocksize (1.45ms in that case), the shift you see is just a rounding error.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
vsnapshot~? Where can I find it's help? (I use Ubuntu PD(not extended) and PD 0.40-2)
Sorry, I was wrong of course: As Roman correclty mentioned, it's not really possible to use switch-and-ramp with vline~/vsnapshot~. Actually I found this out as well in that past list thread, but forgot about it. ;)
I still see inconsistencies in the patch I submitted I will try to make something a little clearer: please try the new attached patches and tell me why the little bit before the ramp changes size (I suspect that is the size of one block, sometimes there, sometimes not). How can I make this consistent?
I attached a reworked version of that example which compares both the line~ and vline~ switch-and-ramp techniques. I'm now using much smaller delay times, so it's easier to see what's happening accross the block boundaries. With vline~/vsnapshot (left part) you'll see that the ramp starts at a wrong position. That's because vsnapshot~ reports the signal value too late, so the original ramp already is at a different position. With line~/snapshot~ this doesn't happen (right part of patch, you need a big enough screen.)
Ciao
Frank Barknecht _ ______footils.org__
This seems to be a fundamental limitation with block-based DSP panguages - you can get 1-sample DSP/control/DSP turnaround only if you're content to wait for the next block boundary -- if you want to be able to name any sample you want, then the minimum turnaround delay is one block. I waxed a bit on that in Chapter 3 of Techniques, but I think the subject is so abstruse that nobody actuallly reads that chapter :)
M
On Thu, Oct 04, 2007 at 03:59:20PM +0200, Frank Barknecht wrote:
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
vsnapshot~? Where can I find it's help? (I use Ubuntu PD(not extended) and PD 0.40-2)
Sorry, I was wrong of course: As Roman correclty mentioned, it's not really possible to use switch-and-ramp with vline~/vsnapshot~. Actually I found this out as well in that past list thread, but forgot about it. ;)
I still see inconsistencies in the patch I submitted I will try to make something a little clearer: please try the new attached patches and tell me why the little bit before the ramp changes size (I suspect that is the size of one block, sometimes there, sometimes not). How can I make this consistent?
I attached a reworked version of that example which compares both the line~ and vline~ switch-and-ramp techniques. I'm now using much smaller delay times, so it's easier to see what's happening accross the block boundaries. With vline~/vsnapshot (left part) you'll see that the ramp starts at a wrong position. That's because vsnapshot~ reports the signal value too late, so the original ramp already is at a different position. With line~/snapshot~ this doesn't happen (right part of patch, you need a big enough screen.)
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Frank Barknecht -
Miller Puckette -
Roman Haefeli -
Thomas O Fredericks