[PD] bendin bug (?)

[Derek Kwan]

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 at 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 at gmail.com>
> > *To:* Giulio Moro <giuliomoro at yahoo.it>
> > *Cc:* Miller Puckette <msp at ucsd.edu>; "pd-list at lists.iem.at" <
> > pd-list at 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 at 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
> >
> >
> >