Howdy, so I'm cloning the scale object from Max, to make an object and include in the cyclone library. It converts range input (low_in / high_in) to a range output (low_out / high_out). It has a logarithmic curve for rescaling according to a fifth argument/inlet. I did copy into expr the formula described in the reference of Max6/7 (max's 5 was just wrong, copied from [linedrive]) - well, it didn't work! Would anyone know if I'm doing something wrong or if the reference is not telling the truth?
The formula, as described in the reference is: (out_low + (out_high-out_low)
- ( (out_high - out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(x
- log(power)) ))
Here's my patch with that formula into expr. The output with the parameters I have should be -0.997347 - as that's the output I get in Max. But instead, it's giving -0.994694...
thanks
=================
#N canvas 24 23 488 340 10;
#X obj 215 154 v out_low;
#X obj 233 132 v out_high;
#X obj 288 110 v power;
#X obj 152 130 v in_high;
#X obj 115 153 v in_low;
#X floatatom 58 248 0 0 0 0 - - -;
#X obj 58 197 expr (out_low + (out_high-out_low) * ( (out_high - out_low)
- exp(-1*(in_high-in_low)*log(power)) * exp($f1*log(power)) ));
#X msg 115 102 0;
#X msg 152 102 127;
#X msg 215 99 -1;
#X msg 249 97 1;
#X msg 288 86 1.06;
#X obj 90 31 loadbang;
#X obj 90 60 t b b;
#X msg 58 107 13.3;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 3 0;
#X connect 9 0 0 0;
#X connect 10 0 1 0;
#X connect 11 0 2 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 13 1 11 0;
#X connect 13 1 10 0;
#X connect 13 1 9 0;
#X connect 13 1 8 0;
#X connect 13 1 7 0;
#X connect 14 0 6 0;
You're using the [scale] formula from @classic_mode in Max7, which exists for compatibility with IRCAM, but it's clearly wrong. (There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1. Just try a few different exponents and you'll see that there's a bug in the Max code. And there are lots of bug reports out there about it.)
That's why they introduced an alternate mode for [scale] in Max, which can be switch in the Inspector.
For non-classic (modern) mode, the documentation gives you this equation:
((x-in_low)/(in_high-in_low) == 0) ? out_low : (((x-in_low)/(in_high-in_low)) > 0) ? (out_low + (out_high-out_low) * ((x-in_low)/(in_high-in_low))^exp) : ( out_low + (out_high-out_low) * -((((-x+in_low)/(in_high-in_low)))^(exp)))
Translated to expr as:
[expr if ((($f1-in_low)/(in_high-in_low)==0), out_low, if ((($f1-in_low)/(in_high-in_low)>0), out_low+(out_high-out_low)*pow(($f1-in_low)/(in_high-in_low), power), out_low+(out_high-out_low)*-1*pow((-1*$f1+in_low)/(in_high-in_low), power)))]
Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072.
Joel
On 06/19/2015 05:39 PM, Alexandre Torres Porres wrote:
Howdy, so I'm cloning the scale object from Max, to make an object and include in the cyclone library. It converts range input (low_in / high_in) to a range output (low_out / high_out). It has a logarithmic curve for rescaling according to a fifth argument/inlet. I did copy into expr the formula described in the reference of Max6/7 (max's 5 was just wrong, copied from [linedrive]) - well, it didn't work! Would anyone know if I'm doing something wrong or if the reference is not telling the truth?
The formula, as described in the reference is: (out_low + (out_high-out_low) * ( (out_high - out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(x * log(power)) ))
Here's my patch with that formula into expr. The output with the parameters I have should be -0.997347 - as that's the output I get in Max. But instead, it's giving -0.994694...
thanks
=================
#N canvas 24 23 488 340 10;
#X obj 215 154 v out_low;
#X obj 233 132 v out_high;
#X obj 288 110 v power;
#X obj 152 130 v in_high;
#X obj 115 153 v in_low;
#X floatatom 58 248 0 0 0 0 - - -;
#X obj 58 197 expr (out_low + (out_high-out_low) * ( (out_high - out_low)
- exp(-1*(in_high-in_low)*log(power)) * exp($f1*log(power)) ));
#X msg 115 102 0;
#X msg 152 102 127;
#X msg 215 99 -1;
#X msg 249 97 1;
#X msg 288 86 1.06;
#X obj 90 31 loadbang;
#X obj 90 60 t b b;
#X msg 58 107 13.3;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 3 0;
#X connect 9 0 0 0;
#X connect 10 0 1 0;
#X connect 11 0 2 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 13 1 11 0;
#X connect 13 1 10 0;
#X connect 13 1 9 0;
#X connect 13 1 8 0;
#X connect 13 1 7 0;
#X connect 14 0 6 0;
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yeah, I see all that, but the problem is trying to clone it as it is in Max for the sake of compatibility.
I wouldn't say that the classic mode is "wrong", it may be not good for the purpose, but it's an arbitrary mathematical formula, so it is what it is.
The problem is that I'm not being able to get the result the object spits out with the formula given in the reference.
So my question is just making it sure that the given formula is wrong, and that it doesn't give what the object actually does.
moreover, the idea is to keep compatibility, at first, with Max5. In Max7 the scale object will still give the same results (as default, by the way), so even if it was for the sake of making it compatible with Max7, we'd still need to make it work. But the thing is that the new "not classic" mode was introduced only in Max6. So, for the actual purpose, we're only caring about the classic mode compatibility.
did you check if the formula in the reference is actually wrong, in the sense it won't give the results given by the object? Were you able to spot a parenthesis out of place or something that, if changed, would give the expected result?
thanks
cheers
2015-06-19 22:25 GMT-03:00 Joel Matthys jwmatthys@gmail.com:
You're using the [scale] formula from @classic_mode in Max7, which exists for compatibility with IRCAM, but it's clearly wrong. (There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1. Just try a few different exponents and you'll see that there's a bug in the Max code. And there are lots of bug reports out there about it.)
That's why they introduced an alternate mode for [scale] in Max, which can be switch in the Inspector.
For non-classic (modern) mode, the documentation gives you this equation:
((x-in_low)/(in_high-in_low) == 0) ? out_low : (((x-in_low)/(in_high-in_low)) > 0) ? (out_low + (out_high-out_low) * ((x-in_low)/(in_high-in_low))^exp) : ( out_low + (out_high-out_low) * -((((-x+in_low)/(in_high-in_low)))^(exp)))
Translated to expr as:
[expr if ((($f1-in_low)/(in_high-in_low)==0), out_low, if ((($f1-in_low)/(in_high-in_low)>0), out_low+(out_high-out_low)*pow(($f1-in_low)/(in_high-in_low), power), out_low+(out_high-out_low)*-1*pow((-1*$f1+in_low)/(in_high-in_low), power)))]
Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072.
Joel
On 06/19/2015 05:39 PM, Alexandre Torres Porres wrote:
Howdy, so I'm cloning the scale object from Max, to make an object and include in the cyclone library. It converts range input (low_in / high_in) to a range output (low_out / high_out). It has a logarithmic curve for rescaling according to a fifth argument/inlet. I did copy into expr the formula described in the reference of Max6/7 (max's 5 was just wrong, copied from [linedrive]) - well, it didn't work! Would anyone know if I'm doing something wrong or if the reference is not telling the truth?
The formula, as described in the reference is: (out_low + (out_high-out_low)
- ( (out_high - out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(x
- log(power)) ))
Here's my patch with that formula into expr. The output with the parameters I have should be -0.997347 - as that's the output I get in Max. But instead, it's giving -0.994694...
thanks
=================
#N canvas 24 23 488 340 10;
#X obj 215 154 v out_low;
#X obj 233 132 v out_high;
#X obj 288 110 v power;
#X obj 152 130 v in_high;
#X obj 115 153 v in_low;
#X floatatom 58 248 0 0 0 0 - - -;
#X obj 58 197 expr (out_low + (out_high-out_low) * ( (out_high - out_low)
- exp(-1*(in_high-in_low)*log(power)) * exp($f1*log(power)) ));
#X msg 115 102 0;
#X msg 152 102 127;
#X msg 215 99 -1;
#X msg 249 97 1;
#X msg 288 86 1.06;
#X obj 90 31 loadbang;
#X obj 90 60 t b b;
#X msg 58 107 13.3;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 3 0;
#X connect 9 0 0 0;
#X connect 10 0 1 0;
#X connect 11 0 2 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 13 1 11 0;
#X connect 13 1 10 0;
#X connect 13 1 9 0;
#X connect 13 1 8 0;
#X connect 13 1 7 0;
#X connect 14 0 6 0;
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I just don't see the value of trying to make it compatible with broken code in Max.
Joel
On 06/19/2015 08:47 PM, Alexandre Torres Porres wrote:
yeah, I see all that, but the problem is trying to clone it as it is in Max for the sake of compatibility.
I wouldn't say that the classic mode is "wrong", it may be not good for the purpose, but it's an arbitrary mathematical formula, so it is what it is.
The problem is that I'm not being able to get the result the object spits out with the formula given in the reference.
So my question is just making it sure that the given formula is wrong, and that it doesn't give what the object actually does.
moreover, the idea is to keep compatibility, at first, with Max5. In Max7 the scale object will still give the same results (as default, by the way), so even if it was for the sake of making it compatible with Max7, we'd still need to make it work. But the thing is that the new "not classic" mode was introduced only in Max6. So, for the actual purpose, we're only caring about the classic mode compatibility.
did you check if the formula in the reference is actually wrong, in the sense it won't give the results given by the object? Were you able to spot a parenthesis out of place or something that, if changed, would give the expected result?
thanks
cheers
2015-06-19 22:25 GMT-03:00 Joel Matthys <jwmatthys@gmail.com mailto:jwmatthys@gmail.com>:
You're using the [scale] formula from @classic_mode in Max7, which exists for compatibility with IRCAM, but it's clearly wrong. (There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1. Just try a few different exponents and you'll see that there's a bug in the Max code. And there are lots of bug reports out there about it.) That's why they introduced an alternate mode for [scale] in Max, which can be switch in the Inspector. For non-classic (modern) mode, the documentation gives you this equation: ((x-in_low)/(in_high-in_low) == 0) ? out_low : (((x-in_low)/(in_high-in_low)) > 0) ? (out_low + (out_high-out_low) * ((x-in_low)/(in_high-in_low))^exp) : ( out_low + (out_high-out_low) * -((((-x+in_low)/(in_high-in_low)))^(exp))) Translated to expr as: [expr if ((($f1-in_low)/(in_high-in_low)==0), out_low, if ((($f1-in_low)/(in_high-in_low)>0), out_low+(out_high-out_low)*pow(($f1-in_low)/(in_high-in_low), power), out_low+(out_high-out_low)*-1*pow((-1*$f1+in_low)/(in_high-in_low), power)))] Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072. Joel On 06/19/2015 05:39 PM, Alexandre Torres Porres wrote:Howdy, so I'm cloning the scale object from Max, to make an object and include in the cyclone library. It converts range input (low_in / high_in) to a range output (low_out / high_out). It has a logarithmic curve for rescaling according to a fifth argument/inlet. I did copy into expr the formula described in the reference of Max6/7 (max's 5 was just wrong, copied from [linedrive]) - well, it didn't work! Would anyone know if I'm doing something wrong or if the reference is not telling the truth? The formula, as described in the reference is: (out_low + (out_high-out_low) * ( (out_high - out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(x * log(power)) )) Here's my patch with that formula into expr. The output with the parameters I have should be -0.997347 - as that's the output I get in Max. But instead, it's giving -0.994694... thanks ================= #N canvas 24 23 488 340 10; #X obj 215 154 v out_low; #X obj 233 132 v out_high; #X obj 288 110 v power; #X obj 152 130 v in_high; #X obj 115 153 v in_low; #X floatatom 58 248 0 0 0 0 - - -; #X obj 58 197 expr (out_low + (out_high-out_low) * ( (out_high - out_low) * exp(-1*(in_high-in_low)*log(power)) * exp($f1*log(power)) )); #X msg 115 102 0; #X msg 152 102 127; #X msg 215 99 -1; #X msg 249 97 1; #X msg 288 86 1.06; #X obj 90 31 loadbang; #X obj 90 60 t b b; #X msg 58 107 13.3; #X connect 6 0 5 0; #X connect 7 0 4 0; #X connect 8 0 3 0; #X connect 9 0 0 0; #X connect 10 0 1 0; #X connect 11 0 2 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 13 1 11 0; #X connect 13 1 10 0; #X connect 13 1 9 0; #X connect 13 1 8 0; #X connect 13 1 7 0; #X connect 14 0 6 0; _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Well, I'm trying to point out that it ain't "broken", the object works... whatever its code is. I'm just trying to figure out the code to clone it.
2015-06-19 22:55 GMT-03:00 Joel Matthys jwmatthys@gmail.com:
I just don't see the value of trying to make it compatible with broken code in Max.
Joel
On 06/19/2015 08:47 PM, Alexandre Torres Porres wrote:
yeah, I see all that, but the problem is trying to clone it as it is in Max for the sake of compatibility.
I wouldn't say that the classic mode is "wrong", it may be not good for the purpose, but it's an arbitrary mathematical formula, so it is what it is.
The problem is that I'm not being able to get the result the object spits out with the formula given in the reference.
So my question is just making it sure that the given formula is wrong, and that it doesn't give what the object actually does.
moreover, the idea is to keep compatibility, at first, with Max5. In Max7 the scale object will still give the same results (as default, by the way), so even if it was for the sake of making it compatible with Max7, we'd still need to make it work. But the thing is that the new "not classic" mode was introduced only in Max6. So, for the actual purpose, we're only caring about the classic mode compatibility.
did you check if the formula in the reference is actually wrong, in the sense it won't give the results given by the object? Were you able to spot a parenthesis out of place or something that, if changed, would give the expected result?
thanks
cheers
2015-06-19 22:25 GMT-03:00 Joel Matthys jwmatthys@gmail.com:
You're using the [scale] formula from @classic_mode in Max7, which exists for compatibility with IRCAM, but it's clearly wrong. (There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1. Just try a few different exponents and you'll see that there's a bug in the Max code. And there are lots of bug reports out there about it.)
That's why they introduced an alternate mode for [scale] in Max, which can be switch in the Inspector.
For non-classic (modern) mode, the documentation gives you this equation:
((x-in_low)/(in_high-in_low) == 0) ? out_low : (((x-in_low)/(in_high-in_low)) > 0) ? (out_low + (out_high-out_low) * ((x-in_low)/(in_high-in_low))^exp) : ( out_low + (out_high-out_low) * -((((-x+in_low)/(in_high-in_low)))^(exp)))
Translated to expr as:
[expr if ((($f1-in_low)/(in_high-in_low)==0), out_low, if ((($f1-in_low)/(in_high-in_low)>0), out_low+(out_high-out_low)*pow(($f1-in_low)/(in_high-in_low), power), out_low+(out_high-out_low)*-1*pow((-1*$f1+in_low)/(in_high-in_low), power)))]
Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072.
Joel
On 06/19/2015 05:39 PM, Alexandre Torres Porres wrote:
Howdy, so I'm cloning the scale object from Max, to make an object and include in the cyclone library. It converts range input (low_in / high_in) to a range output (low_out / high_out). It has a logarithmic curve for rescaling according to a fifth argument/inlet. I did copy into expr the formula described in the reference of Max6/7 (max's 5 was just wrong, copied from [linedrive]) - well, it didn't work! Would anyone know if I'm doing something wrong or if the reference is not telling the truth?
The formula, as described in the reference is: (out_low + (out_high-out_low)
- ( (out_high - out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(x
- log(power)) ))
Here's my patch with that formula into expr. The output with the parameters I have should be -0.997347 - as that's the output I get in Max. But instead, it's giving -0.994694...
thanks
=================
#N canvas 24 23 488 340 10;
#X obj 215 154 v out_low;
#X obj 233 132 v out_high;
#X obj 288 110 v power;
#X obj 152 130 v in_high;
#X obj 115 153 v in_low;
#X floatatom 58 248 0 0 0 0 - - -;
#X obj 58 197 expr (out_low + (out_high-out_low) * ( (out_high - out_low)
- exp(-1*(in_high-in_low)*log(power)) * exp($f1*log(power)) ));
#X msg 115 102 0;
#X msg 152 102 127;
#X msg 215 99 -1;
#X msg 249 97 1;
#X msg 288 86 1.06;
#X obj 90 31 loadbang;
#X obj 90 60 t b b;
#X msg 58 107 13.3;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 3 0;
#X connect 9 0 0 0;
#X connect 10 0 1 0;
#X connect 11 0 2 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 13 1 11 0;
#X connect 13 1 10 0;
#X connect 13 1 9 0;
#X connect 13 1 8 0;
#X connect 13 1 7 0;
#X connect 14 0 6 0;
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/20/2015 03:55 AM, Joel Matthys wrote:
I just don't see the value of trying to make it compatible with broken code in Max.
the sole purpose of cyclone is to provide compatibility with max: if you have a max(<5) patch, it makes it trivial to port it to Pd.
compatibility also means keeping (functionality) bugs.
if you don't care about compatibility, there are plenty of other externals out there, that might fit your bill.
gfdsamr IOhannes
compatibility also means keeping (functionality) bugs.
Yes it does! But, anyway, the point is that I do not really see a "bug" here...
2015-06-20 15:51 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 06/20/2015 03:55 AM, Joel Matthys wrote:
I just don't see the value of trying to make it compatible with broken code in Max.
the sole purpose of cyclone is to provide compatibility with max: if you have a max(<5) patch, it makes it trivial to port it to Pd.
compatibility also means keeping (functionality) bugs.
if you don't care about compatibility, there are plenty of other externals out there, that might fit your bill.
gfdsamr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Some guy in the MAX/MSP facebook group was able to reverse engineer and find the formula.
It's [expr out_low + (out_high-out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(($f1 - in_low) * log(power))], and it seems to just WORK PERFECTLY!!
A few more test, and I can get on to cloning it... the formula in the reference was just a lot of bull crap...
cheers
2015-06-20 16:37 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
compatibility also means keeping (functionality) bugs.
Yes it does! But, anyway, the point is that I do not really see a "bug" here...
2015-06-20 15:51 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 06/20/2015 03:55 AM, Joel Matthys wrote:
I just don't see the value of trying to make it compatible with broken code in Max.
the sole purpose of cyclone is to provide compatibility with max: if you have a max(<5) patch, it makes it trivial to port it to Pd.
compatibility also means keeping (functionality) bugs.
if you don't care about compatibility, there are plenty of other externals out there, that might fit your bill.
gfdsamr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1
well, there wouldn't be a way if it were a linear scaling... but it's a logarithmic scale, so it'll do what it does.
Just try a few different exponents and you'll see that there's a bug in the Max code.
which bug exactly? I tried other values close to the "typical value" they mention (1.06) and it doesn't seem weird to me. Not typical values will given untypical and not so useful results, but they warn you about it.
there are lots of bug reports out there about it.
About the object or the conversion formula? cause if it is about the object, it could be anything. Now, if the object does not convert according to the supposed math, it'd be reasonable that they'd have it fixed eventually. Is this really the case? I hope you could be more specific about the issue. I'd like to know that please, now that I'm working with this.
Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072.
To be honest, I don't think the non classic mode is that much sensible. It'd make much more sense to me to specify a power exponential.
Anyway, it may be more sensible after all, but this fact alone is not enough to say the other one is "wrong" or "broken" - you can just say it isn't "sensible"... which is true.
What we know is that the given formula in the reference for the non classic mode is in accordance to what the object outputs. I had tested that by the way, and saw it was accurate.
I'm just asking to make sure if the other given formula given in the reference is actually wrong, or if I made a mistake. It seems clear for us that it is not outputting what the object is, so the reference seems just wrong.
If the reference is wrong, it doesn't mean the object is "broken" or "wrong". And talking about being sensible, the output of the given formula is even crazier and all... so it's not like the object should output that, it's more like "hey, the reference is wrong, and we don't know the formula to clone it!"
About the other inquiry on what would I want to clone an object that behaves arguably insensibly, the answer is just that I'd like to clone it for the purpose of cloning it. Whatever it is, I'd like to make an exact copy of it. That's the purpose of cyclone after all.
cheers
2015-06-19 22:25 GMT-03:00 Joel Matthys jwmatthys@gmail.com:
You're using the [scale] formula from @classic_mode in Max7, which exists for compatibility with IRCAM, but it's clearly wrong. (There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1. Just try a few different exponents and you'll see that there's a bug in the Max code. And there are lots of bug reports out there about it.)
That's why they introduced an alternate mode for [scale] in Max, which can be switch in the Inspector.
For non-classic (modern) mode, the documentation gives you this equation:
((x-in_low)/(in_high-in_low) == 0) ? out_low : (((x-in_low)/(in_high-in_low)) > 0) ? (out_low + (out_high-out_low) * ((x-in_low)/(in_high-in_low))^exp) : ( out_low + (out_high-out_low) * -((((-x+in_low)/(in_high-in_low)))^(exp)))
Translated to expr as:
[expr if ((($f1-in_low)/(in_high-in_low)==0), out_low, if ((($f1-in_low)/(in_high-in_low)>0), out_low+(out_high-out_low)*pow(($f1-in_low)/(in_high-in_low), power), out_low+(out_high-out_low)*-1*pow((-1*$f1+in_low)/(in_high-in_low), power)))]
Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072.
Joel
On 06/19/2015 05:39 PM, Alexandre Torres Porres wrote:
Howdy, so I'm cloning the scale object from Max, to make an object and include in the cyclone library. It converts range input (low_in / high_in) to a range output (low_out / high_out). It has a logarithmic curve for rescaling according to a fifth argument/inlet. I did copy into expr the formula described in the reference of Max6/7 (max's 5 was just wrong, copied from [linedrive]) - well, it didn't work! Would anyone know if I'm doing something wrong or if the reference is not telling the truth?
The formula, as described in the reference is: (out_low + (out_high-out_low)
- ( (out_high - out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(x
- log(power)) ))
Here's my patch with that formula into expr. The output with the parameters I have should be -0.997347 - as that's the output I get in Max. But instead, it's giving -0.994694...
thanks
=================
#N canvas 24 23 488 340 10;
#X obj 215 154 v out_low;
#X obj 233 132 v out_high;
#X obj 288 110 v power;
#X obj 152 130 v in_high;
#X obj 115 153 v in_low;
#X floatatom 58 248 0 0 0 0 - - -;
#X obj 58 197 expr (out_low + (out_high-out_low) * ( (out_high - out_low)
- exp(-1*(in_high-in_low)*log(power)) * exp($f1*log(power)) ));
#X msg 115 102 0;
#X msg 152 102 127;
#X msg 215 99 -1;
#X msg 249 97 1;
#X msg 288 86 1.06;
#X obj 90 31 loadbang;
#X obj 90 60 t b b;
#X msg 58 107 13.3;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 3 0;
#X connect 9 0 0 0;
#X connect 10 0 1 0;
#X connect 11 0 2 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 13 1 11 0;
#X connect 13 1 10 0;
#X connect 13 1 9 0;
#X connect 13 1 8 0;
#X connect 13 1 7 0;
#X connect 14 0 6 0;
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
To be honest, I don't think the non classic mode is that much sensible. It'd make much more sense to me to specify a power exponential.
I take this back, because that what it does after all, you specify the power exponential :)
I still think we need to clone the classic mode behavior, but I'm surely including this non classic feature from Max7, cause it is as sensible as it gets.
cheers
2015-06-19 23:36 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1
well, there wouldn't be a way if it were a linear scaling... but it's a logarithmic scale, so it'll do what it does.
Just try a few different exponents and you'll see that there's a bug in the Max code.
which bug exactly? I tried other values close to the "typical value" they mention (1.06) and it doesn't seem weird to me. Not typical values will given untypical and not so useful results, but they warn you about it.
there are lots of bug reports out there about it.
About the object or the conversion formula? cause if it is about the object, it could be anything. Now, if the object does not convert according to the supposed math, it'd be reasonable that they'd have it fixed eventually. Is this really the case? I hope you could be more specific about the issue. I'd like to know that please, now that I'm working with this.
Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072.
To be honest, I don't think the non classic mode is that much sensible. It'd make much more sense to me to specify a power exponential.
Anyway, it may be more sensible after all, but this fact alone is not enough to say the other one is "wrong" or "broken" - you can just say it isn't "sensible"... which is true.
What we know is that the given formula in the reference for the non classic mode is in accordance to what the object outputs. I had tested that by the way, and saw it was accurate.
I'm just asking to make sure if the other given formula given in the reference is actually wrong, or if I made a mistake. It seems clear for us that it is not outputting what the object is, so the reference seems just wrong.
If the reference is wrong, it doesn't mean the object is "broken" or "wrong". And talking about being sensible, the output of the given formula is even crazier and all... so it's not like the object should output that, it's more like "hey, the reference is wrong, and we don't know the formula to clone it!"
About the other inquiry on what would I want to clone an object that behaves arguably insensibly, the answer is just that I'd like to clone it for the purpose of cloning it. Whatever it is, I'd like to make an exact copy of it. That's the purpose of cyclone after all.
cheers
2015-06-19 22:25 GMT-03:00 Joel Matthys jwmatthys@gmail.com:
You're using the [scale] formula from @classic_mode in Max7, which exists for compatibility with IRCAM, but it's clearly wrong. (There's no way mapping 13.3 from 0-127 to -1 to 1 should result in something so close to -1. Just try a few different exponents and you'll see that there's a bug in the Max code. And there are lots of bug reports out there about it.)
That's why they introduced an alternate mode for [scale] in Max, which can be switch in the Inspector.
For non-classic (modern) mode, the documentation gives you this equation:
((x-in_low)/(in_high-in_low) == 0) ? out_low : (((x-in_low)/(in_high-in_low)) > 0) ? (out_low + (out_high-out_low) * ((x-in_low)/(in_high-in_low))^exp) : ( out_low + (out_high-out_low) * -((((-x+in_low)/(in_high-in_low)))^(exp)))
Translated to expr as:
[expr if ((($f1-in_low)/(in_high-in_low)==0), out_low, if ((($f1-in_low)/(in_high-in_low)>0), out_low+(out_high-out_low)*pow(($f1-in_low)/(in_high-in_low), power), out_low+(out_high-out_low)*-1*pow((-1*$f1+in_low)/(in_high-in_low), power)))]
Switch off classic mode in the inspector in Max7, and you get the same result as expr above, the very sensible -0.817072.
Joel
On 06/19/2015 05:39 PM, Alexandre Torres Porres wrote:
Howdy, so I'm cloning the scale object from Max, to make an object and include in the cyclone library. It converts range input (low_in / high_in) to a range output (low_out / high_out). It has a logarithmic curve for rescaling according to a fifth argument/inlet. I did copy into expr the formula described in the reference of Max6/7 (max's 5 was just wrong, copied from [linedrive]) - well, it didn't work! Would anyone know if I'm doing something wrong or if the reference is not telling the truth?
The formula, as described in the reference is: (out_low + (out_high-out_low)
- ( (out_high - out_low) * exp(-1 * (in_high-in_low) * log(power)) * exp(x
- log(power)) ))
Here's my patch with that formula into expr. The output with the parameters I have should be -0.997347 - as that's the output I get in Max. But instead, it's giving -0.994694...
thanks
=================
#N canvas 24 23 488 340 10;
#X obj 215 154 v out_low;
#X obj 233 132 v out_high;
#X obj 288 110 v power;
#X obj 152 130 v in_high;
#X obj 115 153 v in_low;
#X floatatom 58 248 0 0 0 0 - - -;
#X obj 58 197 expr (out_low + (out_high-out_low) * ( (out_high - out_low)
- exp(-1*(in_high-in_low)*log(power)) * exp($f1*log(power)) ));
#X msg 115 102 0;
#X msg 152 102 127;
#X msg 215 99 -1;
#X msg 249 97 1;
#X msg 288 86 1.06;
#X obj 90 31 loadbang;
#X obj 90 60 t b b;
#X msg 58 107 13.3;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 3 0;
#X connect 9 0 0 0;
#X connect 10 0 1 0;
#X connect 11 0 2 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 13 1 11 0;
#X connect 13 1 10 0;
#X connect 13 1 9 0;
#X connect 13 1 8 0;
#X connect 13 1 7 0;
#X connect 14 0 6 0;
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
IOhannes m zmölnig -
Joel Matthys