_
johan

128 is often more useful than zero. For trough intializing with 128 actually makes a lot of sense for dealing with MIDI values. But someone will always be disappointed in whatever the default setting is.

My pet peeve is that random’s default is zero, which is seriously non-random. Only one of the reasons I wrote my own RNGs in Litter Power.

Not one. There’s a few that default to 128 buffer size but all objects where the argument is used as the numerical value it represents, default to zero with no argument specified, or 1, if there’s a division involved. It’s not really a matter of life or dead, just that I thought it a little inconsistent and I lost 4 precious minutes and 17 dito seconds before I understood why my patch didn’t work properly. And now I’m frivolously spending time writing this, man, I need to go back to work.

_
johan

Yeah, its a documented design bug… ;-)
Even in a Midi centered world it wouldn’t make sense at all…

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

anal, table (size), dial (size), drunk (max, 1st param), to name a few.

Search on ’128′ in the Max Ref, skip page numbers and a few other irrelevant hits, and it’s still a dozen or three objects.

Sorry for being an insufferable Mademoiselle-Jesaistout, but if you directly contradict me, well, red flag before a bull.

Actually, it makes a lot of sense.

Trough searches for minima. It initializes to 128 and the first MIDI value input, *no*matter*what*it*is* is less than that, so becomes the next (first) minimum and stays there until something comes that’s even smaller.

Thanks anyway for proving my initial point: “But someone will always be disappointed in whatever the default setting is.”

Well, all I can say is that it seemed like a good idea at the time. Max was primarily a MIDI program when I wrote peak and trough. The only choices I considered were 127, 128 and maxint. I could make a case for any of them. It doesn’t matter too much at the end of the day, as far as I’m concerned. If we keep this thread going a couple messages longer, it will have taken more time than the original programming effort for trough :-).

-C

–
Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

That’s a nice challenge. Thanks anyway Chris, for the objects. The impression that trough gives is that the first number is always taken as the value to test against all other values. Which would actually be a good scheme, not only for trough and peak, but for change, maximum and minimum as well. Anyhow, I have to admit that for a long time I was not aware of the existence of the sisters peak and trough, and somehow they haven’t made it to the list in my head while programming. Every year or so I rediscover them, like some other objects, mostly on the occasion of reading the entire reference manual in order to prove Peter false : ). Okay, okay, drunk I overlooked, but the others are either ui objects or arguments defining the size of their buffer. Who dares…

_
johan

Oh, well. As Oscar Wilde would have it, when people agree with me I start to think I may be wrong.

– P (contributing to the attempt to exceed Chris’ original programming effort)

??? A default of 0 doesn’t make sense with trough yes, but a default of
128 is still almost as bad compared to a value which could make sense
(2147483647 for ints or the highest possible float which extends my
ability to write down numbers…)

I’d expect, even from the description, that, if it didn’t receive a
value yet, it would take any input as the lowest received yet, no matter
how high it is… (I bet this would disapoint exactly zero users… ;-)

Clearly its coming out of a Midified mind, but that doesn’t mean it ever
made sense or was a good decision…

It scousine peak has the same problem, its initialised with 0 instead of
-2147483648…

But all this isn’t a real problem as one can initialise both with
whatever seems necessary, and its clearly documented…

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

If you’re in a 0-127 universe, 128 is just as close to infinity as 2 billion.

A really hardcore solution for trough would have been to have a Boolean state variable indicating ‘no data received yet’ allowing the object to special-case the first arriving Atom. But then Chris would have had to spend a little more time coding the object than we have spent discussing it. And then he might have written less music. Writing music is good. Speaking of which, I’d like to do some more of that, too. Can I get the forum to ignore a thread for me?

I am also a bull reacting on red flags… ;-)
I guess nobody would complain if trough would take the first received
value as minimum, even if it is higher than 128. I bet nobody would be
disappointed in this case…

Sometimes (not always) it is possible to find a real optimum… And 128
for trough or 0 for peak just isn’t. But we have to keep backward
compatibility anyway… And red flags flooding the list…
But you know and feel the same, as a bull one just can’t resist, even if
its completely irrelevant… ;-)

Happy bull fighting…

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com