hello,
i'm flabbergasted.
how do you all know when a ramp has finished ramping? none of PD's
line/line~/vline~ objects have a mechanism notifying the user that
the end has been reached.
what are your workarounds (apart from recoding the externs) ?
curious
jasch
jasch wrote:
hello,
i'm flabbergasted.
how do you all know when a ramp has finished ramping? none of PD's
line/line~/vline~ objects have a mechanism notifying the user that
the end has been reached.what are your workarounds (apart from recoding the externs) ?
afaik, this has been discussed at least once on this list. try [delay].
fmg.sadr IOhannes
yes, that one i am well aware of.
i'm more concerned about getting the exact edge of the signal vector
line~ finishes in, not some other clock() firing whenever it's done.
i couldn't find anything here: lists.puredata.info/search
are there other/better places to search the list?
thanks
*j
You can also use Line~ or curve~, both from the cyclone lib and included in Pd Extended.
Tom
On 7/15/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
jasch wrote:
hello,
i'm flabbergasted.
how do you all know when a ramp has finished ramping? none of PD's line/line~/vline~ objects have a mechanism notifying the user that the end has been reached.
what are your workarounds (apart from recoding the externs) ?
afaik, this has been discussed at least once on this list. try [delay].
fmg.sadr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Line~ is not the same as line~ But you can simulate Line~'s behavior with Pd's basic objects. See the attached patch.
Tom
On 7/15/07, jasch j@jasch.ch wrote:
hmm, errm, yes well, i'm actually running PDa on an ARM procesor ;=)
anybody wants to port cyclone to PDa ? (hello fixed point DSP...)
/*j {chuckles}
You can also use Line~ or curve~, both from the cyclone lib and included in Pd Extended.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
excellent, and threshold~ is even in PDa
thanks
/*j (off to count cycles)
Line~ is not the same as line~
that much i figured
But you can simulate Line~'s behavior with Pd's basic objects.
yeah, maybe it would be worth it to upgrade line~ and vline~ (if
that's not considered a heresy :)
nobody would mind a second outlet...
On Jul 15, 2007, at 1:24 PM, jasch wrote:
excellent, and threshold~ is even in PDa
thanks
/*j (off to count cycles)
Line~ is not the same as line~
that much i figured
But you can simulate Line~'s behavior with Pd's basic objects.
yeah, maybe it would be worth it to upgrade line~ and vline~ (if that's not considered a heresy :) nobody would mind a second outlet...
I think that it is a great idea to have line, line~, and vline~
output a bang on a second outlet when they finish. There are already
a number of objects that work like this, and I think it's a useful
paradigm here.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
hi jasch and thomas
this approach has some disadvantages. first, [line~] does execute messages only on block boundaries, that means the start is floating somwewhere around between now and 1.45ms later (with blocksize of 64 @ 44100Hz sr), though i don't know if [line~]'s endpoint is quantized to a block boundary as well. however, [threshold~] does send 'bang's on blockboundaries as well. further, if possible, i would avoid 'measuring' the output of [line~] with [threshold~], since that means converting a message to signal and then back from siglal to a message again. this isn't necessary at all here, because [delay] does exactly what you want (see andy's post about the 'why'). to have it _really_ (even subsample) accurate, you could use [vline~]. [vline~] uses scheduled messages (that are generated by [delay], [metro] and probably other objects) to start a ramp at an arbitrary time, not only on the blockboundaries. using a [vline~]/[delay] construction is far the best solution for your needs, i'd say, jasch; and both objects are internals.
roman
On Sun, 2007-07-15 at 16:18 -0400, Thomas O Fredericks wrote:
Line~ is not the same as line~ But you can simulate Line~'s behavior with Pd's basic objects. See the attached patch.
Tom
On 7/15/07, jasch j@jasch.ch wrote:
hmm, errm, yes well, i'm actually running PDa on an ARM procesor ;=)
anybody wants to port cyclone to PDa ? (hello fixed point DSP...)
/*j {chuckles}
You can also use Line~ or curve~, both from the cyclone lib and included in Pd Extended.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
This is not necessary Jasch. In Pd we know that line [line~] has finished because we told it how long to be a priori. Pd does not chain computations as time sequenced events like, when A is finished begin B, when B is complete begin C... It computes everything on the sheet (following right-left depth first order) in "logical time".
I think Frank and Derek have both given very eloquent and thorough explanations of "logical time" behaviour in the past if you search through the archives. Miller explains it in the primary documentation. It takes a little thought to get your head around (well it took me a while for the penny to drop).
If you would like a bang message when [1 300(-[line~] is complete then you merely have to say
[bang(
|
[t b b] | | [del 300] [1 300( | | [outlet done] [line~] | [outlet line]
Even though the evaluation goes right-left and depth first the bang appearing at [outlet done] happens at the **exact** logical time that [line~] is complete.
On Sun, 15 Jul 2007 22:06:28 +0200 jasch j@jasch.ch wrote:
hmm, errm, yes well, i'm actually running PDa on an ARM procesor ;=)
anybody wants to port cyclone to PDa ? (hello fixed point DSP...)
/*j {chuckles}
You can also use Line~ or curve~, both from the cyclone lib and included in Pd Extended.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
If you would like a bang message when [1 300(-[line~] is complete then you merely have to say
[bang( |[t b b] | | [del 300] [1 300( | | [outlet done] [line~] | [outlet line]
Even though the evaluation goes right-left and depth first the bang appearing at [outlet done] happens at the **exact** logical time that [line~] is complete.
As Roman noted it is not exactly exact if you're starting your [line~] and [delay] from a clock-delayed message, because then [delay] will still keep logical time, while [line~] is quantized to 64 samples.
But in practice this generally isn't an issue: If such accuracy is required in an application (e.g. granular synthesis), nobody would (or should) use [line~] anyway, [vline~] is the line to go for here.
If one *really* wants get back the inaccurate block-quantized delays one's used to from Max, attached patch illustrates a possible approach using [bang~].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Nice demo Frank, what was the purpose of the [t3_line~] that Gerhard and Thomas wrote? Is it now deprecated in view of [vline~]? I assume [t3_delay] was a stopgap solution to this block quantize issue, or am I missing something else?
On Mon, 16 Jul 2007 10:10:52 +0200 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
If you would like a bang message when [1 300(-[line~] is complete then you merely have to say
[bang( |[t b b] | | [del 300] [1 300( | | [outlet done] [line~] | [outlet line]
Even though the evaluation goes right-left and depth first the bang appearing at [outlet done] happens at the **exact** logical time that [line~] is complete.
As Roman noted it is not exactly exact if you're starting your [line~] and [delay] from a clock-delayed message, because then [delay] will still keep logical time, while [line~] is quantized to 64 samples.
But in practice this generally isn't an issue: If such accuracy is required in an application (e.g. granular synthesis), nobody would (or should) use [line~] anyway, [vline~] is the line to go for here.
If one *really* wants get back the inaccurate block-quantized delays one's used to from Max, attached patch illustrates a possible approach using [bang~].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Nice demo Frank, what was the purpose of the [t3_line~] that Gerhard and Thomas wrote? Is it now deprecated in view of [vline~]?
Yes, for all I see, vline~ is doing everything, t3_* was doing.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Andy Farnell -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
jasch -
Roman Haefeli -
Thomas O Fredericks