so, bendout takes from -8192 to 8191, but bendin will receive from 0 to 16383, which is inconsistent with the bendin message, can it be considered a bug and fixed?
cheers
Is this a [bendin] or a [bendout] bug? [bendin]'s current implementation is closer to the actual MIDI messages being transmitted.
From: Alexandre Torres Porres <porres@gmail.com>
To: "pd-list@lists.iem.at" pd-list@lists.iem.at Sent: Sunday, 4 September 2016, 17:26 Subject: [PD] bendin bug (?)
so, bendout takes from -8192 to 8191, but bendin will receive from 0 to 16383, which is inconsistent with the bendin message, can it be considered a bug and fixed? cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2016-09-04 13:35 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
Is this a [bendin] or a [bendout] bug?
[bendin]'s current implementation is closer to the actual MIDI messages being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right?
I just care they both are the same, but it seems to me that -8192 to 8191 is the sensible choice
cheers
The specs don't say much about how to interpret the value actually https://www.midi.org/specifications/item/table-1-summary-of-midi-message
"Pitch Bend Change. status: 1110nnnn data: 0lllllll 0mmmmmmm
This message is sent to indicate a change in the pitch bender (wheel or lever, typically). The pitch bender is measured by a fourteen bit value. Center (no pitch change) is 2000H. Sensitivity is a function of the transmitter. (llllll) are the least significant 7 bits. (mmmmmm) are the most significant 7 bits."
From: Alexandre Torres Porres porres@gmail.com To: Giulio Moro giuliomoro@yahoo.it Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Sent: Sunday, 4 September 2016, 19:33 Subject: Re: [PD] bendin bug (?)
2016-09-04 13:35 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
Is this a [bendin] or a [bendout] bug?
[bendin]'s current implementation is closer to the actual MIDI messages being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right?
I just care they both are the same, but it seems to me that -8192 to 8191 is the sensible choice
cheers
well for me a 14-bit number with a range of 16383 is zero based, otherwise I would need an additional bit for the sign.
also nobend=2000H indicates a value from 0 to 16383...
Am Sonntag, 4. September 2016 schrieb Giulio Moro via Pd-list :
The specs don't say much about how to interpret the value actually https://www.midi.org/specifications/item/table-1-summary-of-midi-message
"Pitch Bend Change. status: 1110nnnn data: 0lllllll 0mmmmmmm
This message is sent to indicate a change in the pitch bender (wheel or lever, typically). The pitch bender is measured by a fourteen bit value. Center (no pitch change) is 2000H. Sensitivity is a function of the transmitter. (llllll) are the least significant 7 bits. (mmmmmm) are the most significant 7 bits."
From: Alexandre Torres Porres <porres@gmail.com javascript:;> To: Giulio Moro <giuliomoro@yahoo.it javascript:;> Cc: "pd-list@lists.iem.at javascript:;" <pd-list@lists.iem.at
Sent: Sunday, 4 September 2016, 19:33 Subject: Re: [PD] bendin bug (?)
2016-09-04 13:35 GMT-03:00 Giulio Moro <giuliomoro@yahoo.it
Is this a [bendin] or a [bendout] bug?
[bendin]'s current implementation is closer to the actual MIDI messages
being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right?
I just care they both are the same, but it seems to me that -8192 to 8191
is the sensible choice
cheers
Pd-list@lists.iem.at javascript:; mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
As long as we're on it, I wonder if the pitch bend messages were always 14bit, cause in max, the bendin object is only 127 (a heritage from mid 80s?)
cheers
2016-09-04 17:44 GMT-03:00 Simon Iten itensimon@gmail.com:
well for me a 14-bit number with a range of 16383 is zero based, otherwise I would need an additional bit for the sign.
also nobend=2000H indicates a value from 0 to 16383...
Am Sonntag, 4. September 2016 schrieb Giulio Moro via Pd-list :
The specs don't say much about how to interpret the value actually https://www.midi.org/specifications/item/table-1-summary-of-midi-message
"Pitch Bend Change. status: 1110nnnn data: 0lllllll 0mmmmmmm
This message is sent to indicate a change in the pitch bender (wheel or lever, typically). The pitch bender is measured by a fourteen bit value. Center (no pitch change) is 2000H. Sensitivity is a function of the transmitter. (llllll) are the least significant 7 bits. (mmmmmm) are the most significant 7 bits."
From: Alexandre Torres Porres porres@gmail.com To: Giulio Moro giuliomoro@yahoo.it Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Sent: Sunday, 4 September 2016, 19:33 Subject: Re: [PD] bendin bug (?)
2016-09-04 13:35 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
Is this a [bendin] or a [bendout] bug?
[bendin]'s current implementation is closer to the actual MIDI messages
being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right?
I just care they both are the same, but it seems to me that -8192 to
8191 is the sensible choice
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
afaik they were always 14-bit but many cheap controllers only use 7-bit resolution...
not sure why max would only allow 0-127, maybe you can get float values from it ? :)
Am Montag, 5. September 2016 schrieb Alexandre Torres Porres :
As long as we're on it, I wonder if the pitch bend messages were always 14bit, cause in max, the bendin object is only 127 (a heritage from mid 80s?)
cheers
2016-09-04 17:44 GMT-03:00 Simon Iten <itensimon@gmail.com javascript:_e(%7B%7D,'cvml','itensimon@gmail.com');>:
well for me a 14-bit number with a range of 16383 is zero based, otherwise I would need an additional bit for the sign.
also nobend=2000H indicates a value from 0 to 16383...
Am Sonntag, 4. September 2016 schrieb Giulio Moro via Pd-list :
The specs don't say much about how to interpret the value actually https://www.midi.org/specifications/item/table-1-summary-of-midi-message
"Pitch Bend Change. status: 1110nnnn data: 0lllllll 0mmmmmmm
This message is sent to indicate a change in the pitch bender (wheel or lever, typically). The pitch bender is measured by a fourteen bit value. Center (no pitch change) is 2000H. Sensitivity is a function of the transmitter. (llllll) are the least significant 7 bits. (mmmmmm) are the most significant 7 bits."
From: Alexandre Torres Porres porres@gmail.com To: Giulio Moro giuliomoro@yahoo.it Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Sent: Sunday, 4 September 2016, 19:33 Subject: Re: [PD] bendin bug (?)
2016-09-04 13:35 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
Is this a [bendin] or a [bendout] bug?
[bendin]'s current implementation is closer to the actual MIDI
messages being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right?
I just care they both are the same, but it seems to me that -8192 to
8191 is the sensible choice
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
2016-09-06 9:17 GMT-03:00 Simon Iten itensimon@gmail.com:
not sure why max would only allow 0-127, maybe you can get float values from it ? :)
nope... you need an extra object (xbendin/out) to use 14 bits - silly as f*ck
ok, somebody told me it was only 7 bit back in the day
2016-09-06 20:37 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2016-09-06 9:17 GMT-03:00 Simon Iten itensimon@gmail.com:
not sure why max would only allow 0-127, maybe you can get float values from it ? :)
nope... you need an extra object (xbendin/out) to use 14 bits - silly as f*ck
On Wed, Sep 7, 2016 at 2:48 PM, Alexandre Torres Porres porres@gmail.com wrote:
ok, somebody told me it was only 7 bit back in the day
when 850 AD?
2016-09-07 16:30 GMT-03:00 Billy Stiltner billy.stiltner@gmail.com:
On Wed, Sep 7, 2016 at 2:48 PM, Alexandre Torres Porres porres@gmail.com wrote:
ok, somebody told me it was only 7 bit back in the day
when 850 AD?
no idea when, but I asked it
I agree with Alexandre about what seems sensible, but introducing a change like this will break existing patches.
Is it possible (for all changes like this) to introduce a compatibility mode to get the old behavior?
Yes, any seasoned Pd hacker will know how to fix the scaling. I'm just imagining someone's patch breaks after upgrading and they just want a fast way to get old behavior.
Thanks,
On Sunday, September 4, 2016, Alexandre Torres Porres porres@gmail.com wrote:
2016-09-04 13:35 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
Is this a [bendin] or a [bendout] bug? [bendin]'s current implementation is closer to the actual MIDI messages
being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right? I just care they both are the same, but it seems to me that -8192 to 8191
is the sensible choice
cheers
Hello,
Well, that's basically what Max does. It defaults to the original 0-127 and then you can specify a "hires" mode to use all 14-bits rather than just 8-bits like 0-127 did. We just implemented this for midiparse and midiformat in cyclone, the current version only had the 0-127. So yes, it'd be pretty easy to do. Just default to the 0-127 and have a flag or have a message change the mode to the "hires" mode. I think in terms of a software's life cycle, if you want it to keep getting better and better, something along the line has to break at some point when people figure out better and more efficient ways of implementing things. Look at Python 2 vs 3 or Lua. But I suppose that argument is for a different time and a different thread and you wouldn't necessarily have to break things here anyways =).
Derek
On Sep 04, William Huston wrote:
I agree with Alexandre about what seems sensible, but introducing a change like this will break existing patches.
Is it possible (for all changes like this) to introduce a compatibility mode to get the old behavior?
Yes, any seasoned Pd hacker will know how to fix the scaling. I'm just imagining someone's patch breaks after upgrading and they just want a fast way to get old behavior.
Thanks,
On Sunday, September 4, 2016, Alexandre Torres Porres porres@gmail.com wrote:
2016-09-04 13:35 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
Is this a [bendin] or a [bendout] bug? [bendin]'s current implementation is closer to the actual MIDI messages
being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right? I just care they both are the same, but it seems to me that -8192 to 8191
is the sensible choice
cheers
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
But in pd it is 14-bits already
It's just that both counterparts are not in the same standard, a bug as i see it (bendout is -8192 to 8191 & bendin is 0 to 16383) - bendout is what I consider the usual way to deal with pitch bend, where 0 is no bend up/down.
cheers
2016-09-11 8:15 GMT-03:00 Derek Kwan derek.x.kwan@gmail.com:
Hello,
Well, that's basically what Max does. It defaults to the original 0-127 and then you can specify a "hires" mode to use all 14-bits rather than just 8-bits like 0-127 did. We just implemented this for midiparse and midiformat in cyclone, the current version only had the 0-127. So yes, it'd be pretty easy to do. Just default to the 0-127 and have a flag or have a message change the mode to the "hires" mode. I think in terms of a software's life cycle, if you want it to keep getting better and better, something along the line has to break at some point when people figure out better and more efficient ways of implementing things. Look at Python 2 vs 3 or Lua. But I suppose that argument is for a different time and a different thread and you wouldn't necessarily have to break things here anyways =).
Derek
On Sep 04, William Huston wrote:
I agree with Alexandre about what seems sensible, but introducing a
change
like this will break existing patches.
Is it possible (for all changes like this) to introduce a compatibility mode to get the old behavior?
Yes, any seasoned Pd hacker will know how to fix the scaling. I'm just imagining someone's patch breaks after upgrading and they just want a
fast
way to get old behavior.
Thanks,
On Sunday, September 4, 2016, Alexandre Torres Porres porres@gmail.com wrote:
2016-09-04 13:35 GMT-03:00 Giulio Moro giuliomoro@yahoo.it:
Is this a [bendin] or a [bendout] bug? [bendin]'s current implementation is closer to the actual MIDI
messages
being transmitted.
but in actuality, the not raw standard is from -8192 to 8191 right? I just care they both are the same, but it seems to me that -8192 to
8191
is the sensible choice
cheers
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On Sep 11, Alexandre Torres Porres wrote:
But in pd it is 14-bits already
It's just that both counterparts are not in the same standard, a bug as i see it (bendout is -8192 to 8191 & bendin is 0 to 16383) - bendout is what I consider the usual way to deal with pitch bend, where 0 is no bend up/down.
cheers
oh, well in that case i think it'd be fine to outright change one and break backwards compat =P yeah, the 0 being the middle spot sounds the most intuitive.
Derek
or might also be a valid point of view, I'm in favor of fixing inconsistent things like this even if it means going through a lot of hassle fixing my patches - but william huston proposed this backwards compatibility flag, which is a neat solution
cheers
2016-09-12 9:22 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2016-09-12 11:25, Derek Kwan wrote:
i think it'd be fine to outright change one and break backwards compat
that's most likely because you don't have accumulated a lot of patches that rely on the old behaviour.
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Yet another idea would be to make a new object name (pitchbendin/out) with the correct behavior. (In fact I thought there already was one in Cyclone.)
cheers M
On Mon, Sep 12, 2016 at 03:28:45PM -0300, Alexandre Torres Porres wrote:
or might also be a valid point of view, I'm in favor of fixing inconsistent things like this even if it means going through a lot of hassle fixing my patches - but william huston proposed this backwards compatibility flag, which is a neat solution
cheers
2016-09-12 9:22 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2016-09-12 11:25, Derek Kwan wrote:
i think it'd be fine to outright change one and break backwards compat
that's most likely because you don't have accumulated a lot of patches that rely on the old behaviour.
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I'd second that. I was aware of the bug for many years (although I erroneously thought it was the hardware which was buggy) and adopted my patches to that. I'd prefer not having to deal with broken patches, having to figure out on which pd Version it'll run correctly.
-- Orm
Am Montag, den 12. September 2016 um 14:31:19 Uhr (-0400) schrieb Miller Puckette:
Yet another idea would be to make a new object name (pitchbendin/out) with the correct behavior. (In fact I thought there already was one in Cyclone.)
cheers M
On Mon, Sep 12, 2016 at 03:28:45PM -0300, Alexandre Torres Porres wrote:
or might also be a valid point of view, I'm in favor of fixing inconsistent things like this even if it means going through a lot of hassle fixing my patches - but william huston proposed this backwards compatibility flag, which is a neat solution
cheers
2016-09-12 9:22 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2016-09-12 11:25, Derek Kwan wrote:
i think it'd be fine to outright change one and break backwards compat
that's most likely because you don't have accumulated a lot of patches that rely on the old behaviour.
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2016-09-12 15:31 GMT-03:00 Miller Puckette msp@ucsd.edu:
In fact I thought there already was one in Cyclone.
The one in cyclone is [xbendin] and [xbendout] and they both go from 0 to 1383. I find this pair of objects quite obsolete and I don't know why they were put in cyclone, as they don't do anything different than Pd's bendin/bendout - they are consistent between themselves though.
Max also has bendin/benout, but the 'x' variance seems to be newer and with a different range, cause the old - but still existing - bendin/bendout objects in Max are only 7 bits (from 0 to 127). BTW, Miller, can you confirm pitch bend messages were only 7 bits back in the day? And do you know when this changed to 14 bits?
Funny enough, max has inconsistencies with other objects.
Quite recently, in the 7.2.0 version (Max is now at 7.2.4), the objects [midiformat] and [midiparse] were finally updated to include 14 bits pitch bend messages, via a '@hires' attribute. The ones in cyclone are still only 7 bits (0-127).
We (Me and Derek) just updated these objects in our currently unreleased cyclone update project to include 14 bit pitch bend messages. In conjunction with Pd's [midiin] / [midiout], they can replace [bendin] / [bendout] related objects, but it is just too clumsy for that. And the silly thing is that they chose for them the more intuitive range from -8192 to 8191, making it inconsistent to xbendin/xbendout. We adopted this more intuitive range anyway.
I was then checking bendin/bendout in Pd to see if they were also from -8192 to 8191 and then found this inconsistency.
So, in short: yeah; xbendin/xbendout in cyclone can be used for a consistent range between MIDI in/output. But then I still think these objects are quite obsolete, cause bendin/out are basic elements present in vanilla. And I it is also weird to me to have them as a way to replace existing objects in vanilla.
Yet another idea would be to make a new object name (pitchbendin/out)
Cool. Whatever the solution is, I'm hoping for a vanilla fix so both pitch bend in/out messages are consistent in vanilla. I'm ok with any solution, but I'm just hoping that both make use of the more intuitive -8192 to 8191 range.
cheers
2016-09-12 15:31 GMT-03:00 Miller Puckette msp@ucsd.edu:
Yet another idea would be to make a new object name (pitchbendin/out)
just tell us please if you plan to do this for the next release and when do you think a 0.47-2 version might come out ;)
maybe before the pdcon16?
thanks
As far as intuitiveness is concerned, -1 to 0.999878 is the most intuitive range for me.Just to make a point that intuitiveness is arbitrary. I would encourage to adopt the MIDI specifications and use those numbers [0-16383] OR a normalized value -1 to 0.999878. -8192 to 8191 sits somewhere in between, breaks free from the specs and yet is not intuitive to use. I would also advocate that we should not change the behaviour of an object that has been there for ages, so a +1 for deprecating [bendin] [bendout] for [pitchebendin] [pitchbendout]. MIDI specs are at revision 1.0 and have always been, afaik, so I take it the pitch bend always was supposed to be a double precision value. A further intuition is: switching from single- to double- precision would have broken all existing MIDI devices which implemented running status. Best,Giulio
From: Alexandre Torres Porres <porres@gmail.com>
To: Miller Puckette msp@ucsd.edu Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Sent: Monday, 12 September 2016, 20:01 Subject: Re: [PD] bendin bug (?)
2016-09-12 15:31 GMT-03:00 Miller Puckette msp@ucsd.edu:
In fact I thought there already was one in Cyclone.
The one in cyclone is [xbendin] and [xbendout] and they both go from 0 to 1383. I find this pair of objects quite obsolete and I don't know why they were put in cyclone, as they don't do anything different than Pd's bendin/bendout - they are consistent between themselves though. Max also has bendin/benout, but the 'x' variance seems to be newer and with a different range, cause the old - but still existing - bendin/bendout objects in Max are only 7 bits (from 0 to 127). BTW, Miller, can you confirm pitch bend messages were only 7 bits back in the day? And do you know when this changed to 14 bits? Funny enough, max has inconsistencies with other objects. Quite recently, in the 7.2.0 version (Max is now at 7.2.4), the objects [midiformat] and [midiparse] were finally updated to include 14 bits pitch bend messages, via a '@hires' attribute. The ones in cyclone are still only 7 bits (0-127). We (Me and Derek) just updated these objects in our currently unreleased cyclone update project to include 14 bit pitch bend messages. In conjunction with Pd's [midiin] / [midiout], they can replace [bendin] / [bendout] related objects, but it is just too clumsy for that. And the silly thing is that they chose for them the more intuitive range from -8192 to 8191, making it inconsistent to xbendin/xbendout. We adopted this more intuitive range anyway. I was then checking bendin/bendout in Pd to see if they were also from -8192 to 8191 and then found this inconsistency. So, in short: yeah; xbendin/xbendout in cyclone can be used for a consistent range between MIDI in/output. But then I still think these objects are quite obsolete, cause bendin/out are basic elements present in vanilla. And I it is also weird to me to have them as a way to replace existing objects in vanilla.
Yet another idea would be to make a new object name (pitchbendin/out)
Cool. Whatever the solution is, I'm hoping for a vanilla fix so both pitch bend in/out messages are consistent in vanilla. I'm ok with any solution, but I'm just hoping that both make use of the more intuitive -8192 to 8191 range. cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
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@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
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
ha! good point!there goes my argument.
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, 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@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@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
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
2016-09-12 21:19 GMT-03:00 Derek Kwan derek.x.kwan@gmail.com:
I do like the idea of new objects IF the old ones gradually get phased out.
totally (+1)
Couldn't you simply open older patches with an older version of pd? Even gcc over time requires changes to the source that uses deprecated API.
Best,
-
Alexandre Torres Porres -
Billy Stiltner -
Derek Kwan -
Giulio Moro -
IOhannes m zmoelnig -
Ivica Bukvic -
Miller Puckette -
Orm Finnendahl -
Simon Iten -
William Huston