[PD] [autoscale] first release
cyrille.henry at la-kitchen.fr
Sat Nov 6 00:23:35 CET 2004
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
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.
Hans-Christoph Steiner a écrit :
> On Nov 5, 2004, at 1:53 PM, Frank Barknecht wrote:
>> 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.
> "Information wants to be free."
> -Stewart Brand
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list