Here is the first stab at an [autoscale] object. You set an output range, and it automatically adjusts a stream of numbers to fit in that output range. This is very handy for standardizing mice, joystick, etc. output which is different for each OS and device.
.hc
"Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice, it
can change entire economies."
- Amy Smith
so, nobody responding to this tool? I like it! as an upgrade, you maybe could add something like a setup, where one can just enter highest position, lowest position, which is fixed then, even if I pass over that range (for example if I donŽt want to use the full range of my interface.)
marius.
Hans-Christoph Steiner said:
Here is the first stab at an [autoscale] object. You set an output range, and it automatically adjusts a stream of numbers to fit in that output range. This is very handy for standardizing mice, joystick, etc. output which is different for each OS and device.
.hc
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies."
- Amy Smith
Hallo, Marius Schebella hat gesagt: // Marius Schebella wrote:
so, nobody responding to this tool? I like it!
Uh, I just found it, thanks a lot for reminding me (because as a .zip was send right into my virus box)
Anyways, this is really cool and very useful in lots of situations.
Ciao
Frank Barknecht _ ______footils.org__
On Nov 4, 2004, at 3:19 AM, Frank Barknecht wrote:
Hallo, Marius Schebella hat gesagt: // Marius Schebella wrote:
so, nobody responding to this tool? I like it!
Uh, I just found it, thanks a lot for reminding me (because as a .zip was send right into my virus box)
Anyways, this is really cool and very useful in lots of situations.
I am going to be using it extensively in my [hid] objects... but this
leads me to where it should go from here. I am thinking that I should
incorporate this behavior into the maxlib [scale] object (but the Gem
nameclash is an annoyance... [gem_scale] pretty please :) then Gem
[scale] could go into a separate folder, like "Gem-deprecated", for
backwards compatibility).
If I modified maxlib [scale], four arguments would be the current
behavior, then two arguments would be [autoscale] behavior. But maybe
these things should be kept separate.
.hc
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 4, 2004, at 3:19 AM, Frank Barknecht wrote:
Anyways, this is really cool and very useful in lots of situations.
I am going to be using it extensively in my [hid] objects... but this
leads me to where it should go from here. I am thinking that I should
incorporate this behavior into the maxlib [scale] object (but the Gem
nameclash is an annoyance... [gem_scale] pretty please :) then Gem
[scale] could go into a separate folder, like "Gem-deprecated", for
backwards compatibility).
I actually reverted from using maxlib_scale in rradical and I'm now using an abstraction for scaling. I'm sure, the speed differences are minimal (at least for linear scaling), the abstraction is almost trivial and it's simply one problem less to worry about. So why not keep it as an abstraction?
Ciao
Frank Barknecht _ ______footils.org__
On Nov 5, 2004, at 1:53 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 4, 2004, at 3:19 AM, Frank Barknecht wrote:
Anyways, this is really cool and very useful in lots of situations.
I am going to be using it extensively in my [hid] objects... but this leads me to where it should go from here. I am thinking that I should incorporate this behavior into the maxlib [scale] object (but the Gem nameclash is an annoyance... [gem_scale] pretty please :) then Gem [scale] could go into a separate folder, like "Gem-deprecated", for backwards compatibility).
I actually reverted from using maxlib_scale in rradical and I'm now using an abstraction for scaling. I'm sure, the speed differences are minimal (at least for linear scaling), the abstraction is almost trivial and it's simply one problem less to worry about. So why not keep it as an abstraction?
The question was about whether they should be separate objects or not.
I think I'd prefer it to be written in Pd rather than C, but maxlib's
scale is already there, so I figured I could easily make the
modifications there.
.hc
"Information wants to be free." -Stewart Brand
hello,
I made 2 years ago a "calibration" abstraction for the sensors I use. I distribute this abstraction with the hardware I sell for my work. (could be download somewhere at www.la-kitchen.fr/download/...)
The first thing I notice is that if a patch have to work on lot's of diferents computer, objects like "scale" should be avoid.
so, what I want to say is : if you want to share a patch : don't use "scale", "range", "uzi" or any other object that create nameclash.
As frank says, it's not very hard to make an autoscale as an 100% native pd abstaction. this solution is the only solution that will work everywhere.
making a patch work on a computer is not very hard. making a patch work on all computer is harder.
cyrille
Hans-Christoph Steiner a écrit :
On Nov 5, 2004, at 1:53 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 4, 2004, at 3:19 AM, Frank Barknecht wrote:
Anyways, this is really cool and very useful in lots of situations.
I am going to be using it extensively in my [hid] objects... but this leads me to where it should go from here. I am thinking that I should incorporate this behavior into the maxlib [scale] object (but the Gem nameclash is an annoyance... [gem_scale] pretty please :) then Gem [scale] could go into a separate folder, like "Gem-deprecated", for backwards compatibility).
I actually reverted from using maxlib_scale in rradical and I'm now using an abstraction for scaling. I'm sure, the speed differences are minimal (at least for linear scaling), the abstraction is almost trivial and it's simply one problem less to worry about. So why not keep it as an abstraction?
The question was about whether they should be separate objects or not.
I think I'd prefer it to be written in Pd rather than C, but maxlib's
scale is already there, so I figured I could easily make the
modifications there..hc
"Information wants to be free." -Stewart Brand
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
cyrille henry -
Frank Barknecht -
Hans-Christoph Steiner -
Marius Schebella