well, I guess I pretty much only use notein/out so I don't have a lot of patches with bend info so IOhannes would be right in that regard. I think keeping this inconsisent behavior in the current existing objects would reinforce this behavior in future patches and then when this topic comes up again x years later there's even more reason to not break backwards compat since there'd be many more patches using these objects.
I do like the idea of new objects IF the old ones gradually get phased out. I think it'd be confusing to new users (and old users) if there's two pairs of objects in existence that pretty much do the same thing with slight differences. Plus, I like the minimality/sleekness of Pd and having two very similar objects kinda gunks it up and adds (although admittedly a very minimal) added footprint.
In terms of the actual scaling, I think I'd prefer the ints rather than the floats scaled to [-1, 1). I suppose it's more safe to downscale from ints rather than upscale from floats? Is there enough precision in a 32-bit float to store someting like 1./8192? I'm reading you can have up to 9 digits of precision in the mantissa and 8192 being a power of 2 helps... admittedly I've been kinda fuzzy on these things...
Derek
On Sep 12, Alexandre Torres Porres wrote:
didn't want to cause disturbance.
please, this is no disturbance and I don't represent this list any more than you do, everything I say is also just my opinion and my two cents
If we want to abstract from the implementation
well, if we don't then maybe we should have 2 inputs/output for the Most and Least significant bits from 0-127, cause that is what the specification is... and the '0' point is 64 / 0
anything else is an abstraction
cheers
2016-09-12 16:52 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
it is a "weird" inconsistent standard
I actually mean it is inconsistent with how the data is represented according to the MIDI standard.
now i don't know if you're just pushing to make this point, when 3
people already manifested that this sounds reasonable and intuitive as well.
Signed integer surely does sound more intuitive than unsigned integer, I agree. My point is, if we want to program for intuitiveness, then normalized float is good (possibly with a different rescaling for the positive part, so that -1 -> -8192 and 1 -> +8191, either way, it should be clipped to range).
If we want to abstract from the implementation (as both normalized float and signed integer do), then I would advocate for the former, as it makes more sense altogether. Going for the latter is, in my opinion, not much of an improvement over the current situation and I would not bother, ESPECIALLY if it is going to be a breaking change. But then, I only recently subscribed to this mailing list, so I have no idea what practices are already in place in the development of Pd, I was just sharing my opinion on the subject, didn't want to cause disturbance.
Best, Giulio
*From:* Alexandre Torres Porres porres@gmail.com *To:* Giulio Moro giuliomoro@yahoo.it *Cc:* Miller Puckette msp@ucsd.edu; "pd-list@lists.iem.at" < pd-list@lists.iem.at> *Sent:* Monday, 12 September 2016, 20:34 *Subject:* Re: [PD] bendin bug (?)
2016-09-12 16:14 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
As far as intuitiveness is concerned, -1 to 0.999878 is the most intuitive range for me.
You'll be glad to know that the update in cyclone will include also the -1 to 0.999878 range for you in midiformat/midiparse. I didn't mention, but besides -8192 to 8191 they also included this - but there's no 0-16383 option though.
Just to make a point that intuitiveness is arbitrary.
now i don't know if you're just pushing to make this point, when 3 people already manifested that this sounds reasonable and intuitive as well.
-8192 to 8191 sits somewhere in between, breaks free from the specs and yet is not intuitive to use.
but this is widely used and I've seen it in different occasions. for instance, it is actually even used in Pd's bendout... why? Cause it is something that actually exists! Another example is that it was just introduced in Max's midiformat/midiparse *instead* of the 0-16383 range. I'm sorry but I have to disagree that it is a "weird" inconsistent standard. It is actually the only standard I ever knew until I found these issues. And it is widely used because it is in fact intuitive, 'coz '0' means no pitch bend up or down... Now, ask a newbie what's the middle point in the 0-16383 range?
cheers