I would prefer if the result of the parser would tell the application that the note is supposed to be an 'f' if the key is 'c' or an 'f-sharp' if the key is 'g', but to go one step farther, the application would decide what actual pitch would be assigned to that -- if for example it is a sound generation program, the application may be generating tempered or just intonation, or some other pitch system. (in some cases the hardware may decide this!)
My sound generation application would simply want to know what note to play, and when. Currently it takes an integer to represent the number of tonal divisions above the base and then calculates the parameters for the sound generation algorithm from that. As such I would prefer not to have an ambiguous integer (as mentioned, save work for the calling application ) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rosen Sent: 14 September 2004 15:03 To: [EMAIL PROTECTED] Subject: Re: [abcusers] ABCp output data structure > Well, considering you really need to parse most fields *anyway* in > order for > the parser to have a context for parsing the actual tune data (for example, > if Key is currently G, then the "F" note I just read is actually an F#...), > I'm not sure it makes much sense to leave that decision up to the > calling program. You're going to have the parsed data in a structure > *somewhere* for the parser itself to access -- may as well pass back > that structure as part of the overall output, and save the calling > application extra work. That's a good point, and that brings up something that I was wondering about. Do you think that the parser should figure out the correct pitch or leave that to the app? I think that is what you are suggesting, and it would be my preference, too. In other words, I'm envisoning that the "pitch" field will be an integer that is the that should be sounded. If we have: K:C F K:G F Then the parser would store different notes, an F-natural in the first case and an F-sharp in the second. That, of course, requires the parser to understand the "K:" field, which could be complicated. However, as you point out, somebody has to understand it anyway, so there needs to be a requirement that the K: field be understandable, so any extensions should be well formed and ignorable. Some other fields, like rhythm, might not be as critical, but if you do it one way for K:, you might as well do it the same way for the other fields. Paul Rosen --- Life is a musical, every once in a while the plot stops and you start singing and dancing --- http://home.earthlink.net/~catharsis.music/ http://home.earthlink.net/~theplums/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
