Hi all, I'm a bit confused about the grain rate of [line] the help says that 'the default grain rate is 20 ms' however, when I connect a [delta] to a [line], it shows zero's, while inserting a [speedlim 20] changes that. also some other tests in attached patch. can someone explain ? Thanks, Tim
On Thu, 21 Oct 2010, tim vets wrote:
Hi all,I'm a bit confused about the grain rate of [line] the help says that 'the default grain rate is 20 ms' however, when I connect a [delta] to a [line], it shows zero's, while inserting a [speedlim 20] changes that. also some other tests in attached patch. can someone explain ?
What's this [delta] thing ? There are several externals with the same name, and none of them is named just [delta] in pd-extended.
Instead I used [b]-[fps, mode logical], is that what you mean ?
In your case, 20 ms is an edge case, because [line] is told to reset immediately, at the same logical time as it just output its second value of the ramp. If you try with 19.999 ms it's different already.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Thu, Oct 21, 2010 at 11:11:12AM -0400, Mathieu Bouchard wrote:
On Thu, 21 Oct 2010, tim vets wrote:
Hi all,I'm a bit confused about the grain rate of [line] the help says
that 'the default grain rate is 20 ms' however, when I connect a [delta] to a [line], it shows zero's, while inserting a [speedlim 20] changes that. also some other tests in attached patch. can someone explain ?Instead I used [b]-[fps, mode logical], is that what you mean ?
[t b b] | | [timer]
would be a line-rate-check that doesn't require any externals. See attachement.
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Thu, 21 Oct 2010, Frank Barknecht wrote:
On Thu, Oct 21, 2010 at 11:11:12AM -0400, Mathieu Bouchard wrote:
Instead I used [b]-[fps, mode logical], is that what you mean ?
[t b b] | | [timer]
would be a line-rate-check that doesn't require any externals. See attachement.
But this doesn't show what [fps, mode logical] does.
[fps] tells you how many bangs per second, as an average over each second (or other period of your choice), whereas if there's a pair of bangs every 20 ms, your thing will always display 0, which is especially why I didn't use it. Well, it's not like [fps] is absolutely better : what's absolutely better is to use both tools at once, as this is how you get the most info about what's going on.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On 10/21/2010 03:30 PM, tim vets wrote:
Hi all, I'm a bit confused about the grain rate of [line] the help says that 'the default grain rate is 20 ms' however, when I connect a [delta] to a [line], it shows zero's, while inserting a [speedlim 20] changes that. also some other tests in attached patch. can someone explain ?
as matju already stated, [delta] is something, a lot of people (including me) do not know.
assuming it is the same as: | [t b b] | | [timer] |
then it "looks" like you get "0", whereas in reality you get: [20, 0( [*]
the "20" shows up so incredibly short (and is then overwritten by "0", that you simply cannot see it. [print] usually allows you to track such things, as you not only see the last value, but the entire history.
[*] why? when [line] receives a new target, it will immediately send out the start value, and then (in grain-time ms) the next value until it reaches the target value. in your case this translates to:
will output the next value ("7")
[line], which will immediately output the current value ("7").
since both the start value and the target value are output at the same logical time, [timer] caluculates a time-difference of "0", which will be visible for the next 20ms.
gmadr IOhannes
2010/10/21 IOhannes zmölnig zmoelnig@iem.at
On 10/21/2010 03:30 PM, tim vets wrote:
Hi all, I'm a bit confused about the grain rate of [line] the help says that 'the default grain rate is 20 ms' however, when I connect a [delta] to a [line], it shows zero's, while inserting a [speedlim 20] changes that. also some other tests in attached patch. can someone explain ?
as matju already stated, [delta] is something, a lot of people (including me) do not know.
assuming it is the same as: | [t b b] | | [timer] |
then it "looks" like you get "0", whereas in reality you get: [20, 0( [*]
the "20" shows up so incredibly short (and is then overwritten by "0", that you simply cannot see it. [print] usually allows you to track such things, as you not only see the last value, but the entire history.
[*] why? when [line] receives a new target, it will immediately send out the start value, and then (in grain-time ms) the next value until it reaches the target value. in your case this translates to:
- you generate the first number ("7") and send [7 20( to [line]
- line will immediately output the current value ("0") and after 20ms it
will output the next value ("7")
- at the "same" time, you generate a new value ("9"), and send this to
[line], which will immediately output the current value ("7").
since both the start value and the target value are output at the same logical time, [timer] caluculates a time-difference of "0", which will be visible for the next 20ms.
the way I understood it, [delta] is the equivalent of: [image: delta.png] I also don't know where I got [delta] from, it doesn't seem to have a help patch associated with it. anyways, replacing [delta] with the above gives the same result. but I'm starting to see why... Tim
gmadr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2010/10/21 tim vets timvets@gmail.com
2010/10/21 IOhannes zmölnig zmoelnig@iem.at
On 10/21/2010 03:30 PM, tim vets wrote:
Hi all, I'm a bit confused about the grain rate of [line] the help says that 'the default grain rate is 20 ms' however, when I connect a [delta] to a [line], it shows zero's, while inserting a [speedlim 20] changes that. also some other tests in attached patch. can someone explain ?
as matju already stated, [delta] is something, a lot of people (including me) do not know.
assuming it is the same as: | [t b b] | | [timer] |
then it "looks" like you get "0", whereas in reality you get: [20, 0( [*]
the "20" shows up so incredibly short (and is then overwritten by "0", that you simply cannot see it. [print] usually allows you to track such things, as you not only see the last value, but the entire history.
[*] why? when [line] receives a new target, it will immediately send out the start value, and then (in grain-time ms) the next value until it reaches the target value. in your case this translates to:
- you generate the first number ("7") and send [7 20( to [line]
- line will immediately output the current value ("0") and after 20ms it
will output the next value ("7")
- at the "same" time, you generate a new value ("9"), and send this to
[line], which will immediately output the current value ("7").
since both the start value and the target value are output at the same logical time, [timer] caluculates a time-difference of "0", which will be visible for the next 20ms.
the way I understood it, [delta] is the equivalent of: [image: delta.png] I also don't know where I got [delta] from, it doesn't seem to have a help patch associated with it. anyways, replacing [delta] with the above gives the same result. but I'm starting to see why... Tim
btw: this fixed my 'problem':
[line] | [change] | [delta]
gr, Tim
gmadr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Tim,
On Thu, Oct 21, 2010 at 05:51:20PM +0200, tim vets wrote:
the way I understood it, [delta] is the equivalent of: [image: delta.png] I also don't know where I got [delta] from, it doesn't seem to have a help patch associated with it.
Maybe it's the [delta] from maxlib. I attached its help file.
Btw.: Your delta.png can be simplyfied a bit as:
[t f f]
/
/
[- ]
Frank Barknecht Do You RjDj.me? _ ______footils.org__