Using a joystick pad to send a +1 or -1; when the value changes to +1, I want to increment a value every N ms, and when it is -1, I want it to subtract from the value every N ms.
This will, in effect, cause the value to slide, at speed of N, between 0 and 127. I would also need to have these values limited so they do not slide lower than zero or above 127.
any hints on how to implement this?
thanks!! jjh
A counter driven by a metro with a period N ms has its increment value set to -1, 0 or 1 by messages. Don't forget you need the 0 to halt it. Limits are set by min and max.
This implementatiion has a small bug. When you change direction the last value stored in the float is flushed through so it overshoots by 1 in either direction. But it's simple to understand.
On Thu, 26 Jul 2007 23:45:20 +0100 PROTMAN protman.makes.music@gmail.com wrote:
Using a joystick pad to send a +1 or -1; when the value changes to +1, I want to increment a value every N ms, and when it is -1, I want it to subtract from the value every N ms.
This will, in effect, cause the value to slide, at speed of N, between 0 and 127. I would also need to have these values limited so they do not slide lower than zero or above 127.
any hints on how to implement this?
thanks!! jjh
-- joe j hahn joehahn@gmail.com 773.818.2762 cell
"All is fair in lunch and robot wars." ~___ _____
On Fri, 27 Jul 2007, Andy Farnell wrote:
This implementatiion has a small bug. When you change direction the last value stored in the float is flushed through so it overshoots by 1 in either direction. But it's simple to understand.
That's because you're supposed to use the output of [+] instead of the output of [f]. That's the difference between a post-incrementing counter (usual) and a pre-incrementing counter (what is wanted here)
If you do a pre-incrementing counter with multiple directions or speeds, it's better to make the system driven by the [+]. Then it can use its own right inlet as the counter value. However Pd forces wires to connect only different objects, so you have to use something like [t f] as intermediate for connecting [+] to itself.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
But this is better :) If the limiter is on the output then the counter continues beyond the 0-127 range and goes out of bounds. Putting [clip] (same as min and max together) inside the counter locks the value in range.
What's the best solution to prevent overshoot? I did solve this once before but it used spigots and was ugly imo.
On Fri, 27 Jul 2007 12:28:00 +0100 Andy Farnell padawan12@obiwannabe.co.uk wrote:
A counter driven by a metro with a period N ms has its increment value set to -1, 0 or 1 by messages. Don't forget you need the 0 to halt it. Limits are set by min and max.
This implementatiion has a small bug. When you change direction the last value stored in the float is flushed through so it overshoots by 1 in either direction. But it's simple to understand.
On Thu, 26 Jul 2007 23:45:20 +0100 PROTMAN protman.makes.music@gmail.com wrote:
Using a joystick pad to send a +1 or -1; when the value changes to +1, I want to increment a value every N ms, and when it is -1, I want it to subtract from the value every N ms.
This will, in effect, cause the value to slide, at speed of N, between 0 and 127. I would also need to have these values limited so they do not slide lower than zero or above 127.
any hints on how to implement this?
thanks!! jjh
-- joe j hahn joehahn@gmail.com 773.818.2762 cell
"All is fair in lunch and robot wars." ~___ _____
-- Use the source
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
But this is better :) If the limiter is on the output then the counter continues beyond the 0-127 range and goes out of bounds. Putting [clip] (same as min and max together) inside the counter locks the value in range.
What's the best solution to prevent overshoot? I did solve this once before but it used spigots and was ugly imo.
It's possible even simpler: Instead of a classical counter you can use an accumulator, which is a similar idiom, but has [f ] and [+ ] reversed: [+ ]x[f ]. Then you send the step size instead of a bang into the [+].
The restrict it with [clip] as you would restrict a normal counter with [mod]. It's attached.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 27 Jul 2007, Frank Barknecht wrote:
It's possible even simpler: Instead of a classical counter you can use an accumulator, which is a similar idiom, but has [f ] and [+ ] reversed: [+ ]x[f ]. Then you send the step size instead of a bang into the [+].
Accumulator is the name I usually use for this, but in my other mail I call it "pre-incrementing" instead. This is a reference to C/C++ and old-style machine languages.
The name "C++" itself refers to post-incrementation, to signify that it is an "incremented" C, variable-wise. (value-wise, C+1 already does it)
The other incrementors of C/C++ (variable-wise) are pre-increments, in that the modification of the variable happens before the result is produced, and that result is produced from the new state of the variable. if I write ++C or C+=1 it's a post-increment.
In Pd, post-increment is done by using the output of a [f] variable, whereas pre-increment is done by using the output of the [+ 1] that goes back into the variable.
Actually it's possible also to output like a pre-increment but only put it in the variable when you are finished using it, by changing the wire order, but usually, this distinction does not matter.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Cool Frank and Matju, comparing pre-inc with accum for this is fun.
On Fri, 27 Jul 2007 12:28:00 +0100 Andy Farnell padawan12@obiwannabe.co.uk wrote:
A counter driven by a metro with a period N ms has its increment value set to -1, 0 or 1 by messages. Don't forget you need the 0 to halt it. Limits are set by min and max.
This implementatiion has a small bug. When you change direction the last value stored in the float is flushed through so it overshoots by 1 in either direction. But it's simple to understand.
On Thu, 26 Jul 2007 23:45:20 +0100 PROTMAN protman.makes.music@gmail.com wrote:
Using a joystick pad to send a +1 or -1; when the value changes to +1, I want to increment a value every N ms, and when it is -1, I want it to subtract from the value every N ms.
This will, in effect, cause the value to slide, at speed of N, between 0 and 127. I would also need to have these values limited so they do not slide lower than zero or above 127.
any hints on how to implement this?
thanks!! jjh
-- joe j hahn joehahn@gmail.com 773.818.2762 cell
"All is fair in lunch and robot wars." ~___ _____
-- Use the source
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Cool Frank and Matju, comparing pre-inc with accum for this is fun.
It's very similar. But what I like most about the accumulator idiom is, that it *looks* very much like the normal counter, so you can even *see* the close relation of the two, which also makes the accumulator idiom ease to remember: It's just a counter with the two participants switching places: [f ]x[+ 1] and [+ ]x[f ].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 27 Jul 2007, Frank Barknecht wrote:
Andy Farnell hat gesagt: // Andy Farnell wrote:
Cool Frank and Matju, comparing pre-inc with accum for this is fun.
It's very similar. But what I like most about the accumulator idiom is, that it *looks* very much like the normal counter, so you can even *see* the close relation of the two, which also makes the accumulator idiom ease to remember: It's just a counter with the two participants switching places: [f ]x[+ 1] and [+ ]x[f ].
The position of the incoming and outgoing wires is important in the characterising the pattern. This is most obvious if you make an abstraction/subpatch out of it, because it leads you to really think of [inlet] [outlet] as part of the pattern. In an non-abstraction/subpatch, you have to think about including loose wires as part of the pattern, which is not something that you can do with the Cut or Copy command.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andy Farnell -
Frank Barknecht -
Mathieu Bouchard -
PROTMAN