[PD] bendin bug (?)

[Giulio Moro]

ha! good point!there goes my argument.


 
      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, 21:10
 Subject: Re: [PD] bendin bug (?)
   
> 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 standardI 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

   
 



   
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160912/3eac9315/attachment-0001.html>