Yah. What he said. Ray Keefe wrote: > > From: "Ray Keefe" <ray@...> > > Hi all, > > Midi used 0-127 for program numbers because that fits into 7 bits of data > (Binary mathematics). This is where one of the problems arises between > concept and implementation. The concept was to be able to select a program. > The implementation used allowed up to 128 programs to be accomodated before > a bank change message was required. This was represented by a 7 bit field > in a message. The numbers in this field went from 0 to 127. I assume that > Roland, as many user focussed companies have been known to do, probably > argued internally that people always count from 1, so 1 should be the first > number. The fact that, in the data this was 0, was irrelevant. > > Many software engineers have used the details of their implementation when > describing things to their users and caused great confusion. I know of > several examples where system with 8 choices available (0-7) receive > complaints from users about the fact that they can't select the eight > choice. They can select 1,2,3,4,5,6,7 but 8 will just not happen. Also, > many people treat 0 as no choice rather than an actual choice. This is why > the zero'th row in Excel is Row 1. Many other examples are possible... > > There have been many good suggestions regarding numbering of bars and beats. > Each suggestion has merits. For instance, Beat 3 being the half way point > of a 4 beat bar seems silly from one perspective. Yet it has never hampered > my ability to make music. The idea of representing ticks as a positive > number from one beat or a negative number relative to the beat ahead of it > also has merit. -2 is easier to use than 238 (did I get that right?). > Especially for us decimal creatures. > > As far as counting goes, starting at 1 has some advantages because beat 4 is > the fourth beat, not the fifth beat. The end of the bar is at the end of > the fourth beat in 4/4 time. The segmentation of the measure into fields > does cause some problems though. eg. for a Decimal system, after 4.9 you > expect 5.0, not 4.10. I believe it is this latter issue that causes the > most confusion. We are happy if bars count OK, and many seem happy with > beats starting at 1, but we are used to zero based offsets within the > fractional fields. Maybe just the ticks should be zero based? > > None of this changes the data! It is just the representation we are > discussing. The fundamental data is OK, the implementation is OK, the data > representation to the user is under discussion in a user forum. Sounds > healthy to me. > > Ray