Re: universal music data exchange format
Jon Murphy <[EMAIL PROTECTED]> said: > So my suggestion was only that there be a uniform > notation for transmission that all music software vendors would agree to so > they could accept any other software's transmission. I agree that this would be highly desirable, but, as with all standards, there will be some difficult compromises to negotiate. An example is found in the work of the unicode committee (which I will not diverge into a discussion of). Programs do not like to have multiple ways of naming things, they prefer unique labels; it simplifys the task of parsing documents. The notation of music has a long history, in western europe we consider its formal beginnings to have been published in medieval latin, so its initial terms were Latin. This gives us Maxima, Longa, Breve... as terms for notes of differeing durations. During the late renaissance many of the mysteries of music were of necessity exposed by printed books, which were writen in the language of the people; giving us other names for the same terms - crotchet, quaver...; quarter note, half note... Any standard worth adopting would have to begin by deciding on the terms it will employ, if we settle on the old latin terms we will probably accomodate early music needs, perhaps even better than if we employ more recent terms, but not necessarily; I wonder how the inventions of petrucci, those flags that signified 5:1 proportions for example were termed... Latin had its shortcommings, we might stumble as a result of them. Those members of the committee who find british terms second-nature would have trouble abandoning them; those who find the british terms a puzzle would have trouble adopting them... Tehn, there is the need to see beyond the present need, those of us with a myopic focus on renaissance tablature might miss the need for symbol names for stuff used commonly in the baroque, or in modern guitar tablature; hereis where the value of a committee is seen, providing it has a broad enough membership base. If one then expands the standard to embrace renaissance staff notation, then expands it again to encompass modern staff notation, one runs up against the hyper-modern notations needed for the works of Cage et al. And, one then discovers that there is a committee working on some aspects of that, in order to establish sysmbol names usable in the context of unicode (er, ISO 10646). To get on or off this list see list information at http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html
Re: universal music data exchange format
Marion, I'll make one last try at what I was saying. I was not speaking of eliminating tabulature or staff notation - or any other way of passing music from one person to another. I'll have to be more boring than usual and mention that I spent a long time in data communication - and still have an original copy of the Proposed Standards from mid seventies somewhere in my bookshelves. That standard, which was basically implemented as proposed, had seven levels of activity - the seventh Hell being the raw transmission and machine level handshaking. It is the sixth level I'm thinking of - the assembly of the message into a standard format. Using a parallel standard the various music software programs could be transmitted between the different programs. A header to define the notation, the key, the voices and other relevant things. Then a message body to send the "music". That way any receiving program with the capability of that notation could recreate it. And in fact the header wouldn't need to define the notation, if the standard were done well. The receiving program could be asked to print it in any notation. Notations are a readable representation of music, and each has its value for particular instruments. I read tab for my lute and staff for my harp - and they are convertible from one to the other, we all do that by hand (and some with a computer program). So my suggestion was only that there be a uniform notation for transmission that all music software vendors would agree to so they could accept any other software's transmission. Much music is sent in a graphic format, that is "in effect" a pixel equivalent. Then there is the protocol for "audio transmission". My suggestion is merely that there be a lower level protocol that then can be translated by the receiving program into the desired format. This is only for the data transmission. It would be a difficult task, as all subtleties of notation would have to be covered (like the possible different frets for the same note), but if done it would ease the task of all programmers in the future. BTW, one can reflect pronunciation in print - consider G.B.Shaw's spelling of "fish" - "ghoti" (gh as in enough, o as in the plural of woman, and ti as in motion). Best, Jon To get on or off this list see list information at http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html
Re: universal music data exchange format
Chriostopher, This would seem to be an area where reality has already caught up with science fiction and possibly gone beyond. Alain >It would be cool to >have a data format that would store all of this information and allow printing >in standard or tab notation. You could see the standard notation if you wanted >to get a better sense of the nuances. Also supporting alternate interpretations >with a footnote like feature would be cool. Hmmm ... > >--- [EMAIL PROTECTED] wrote: > > > >>In a message dated 2/18/2005 2:03:17 PM Eastern Standard Time, >>[EMAIL PROTECTED] writes: >>Just to set the record straight, my tab format was designed to >>be e-mailable. This was in the days when there was no internet >>(just a limited arpanet) and mail was sent from computer to >>computer via telephones, and mailing binaries was frowned >>upon. Back when there were as many macs as windows boxes, >>and lots of versions of unix (no linux!) and even VMS. >>(Boy, does that make me feel old!) >> >>Maybe an interesting idea to share, but I have intabulated lute music using >>Wayne's TAB format with my PDA and folding keyboard on airplane trays on >>transatlantic flights. Very simple and functional, therefore. >> >>Kenneth >> >>-- >> >>To get on or off this list see list information at >>http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html >> >> >> > > > > >
Re: universal music data exchange format
Yes, I agree that Wayne's format is very easy to use and perfect for tabbing lute music. Also very portable -- I haven't thought of using a PDA! Tab in general doesn't show when certain voices should start/stop and for that you need to have an understanding of historical counterpoint and the appropriate ficta (and then realize that these rules weren't very standard at all). The need for this knowledge is lessened with standard notation since individual voice durations can be noted. I only say this because it's really important with certain pieces to get the bass notes or inner voices to stop when they're over, especially with intabulations of vocal music. It's one thing to play the tab as written, it's quite another to play it vocally (is this a word?) and the necessary info isn't in the tab. I'm not saying all of this to soapbox or try to educate anybody since most folks on the list know more about this than me! But I do wonder about being stewards of this information for future generations -- and also encouraging the proper perfomance of the music. It would be cool to have a data format that would store all of this information and allow printing in standard or tab notation. You could see the standard notation if you wanted to get a better sense of the nuances. Also supporting alternate interpretations with a footnote like feature would be cool. Hmmm ... --- [EMAIL PROTECTED] wrote: > In a message dated 2/18/2005 2:03:17 PM Eastern Standard Time, > [EMAIL PROTECTED] writes: > Just to set the record straight, my tab format was designed to > be e-mailable. This was in the days when there was no internet > (just a limited arpanet) and mail was sent from computer to > computer via telephones, and mailing binaries was frowned > upon. Back when there were as many macs as windows boxes, > and lots of versions of unix (no linux!) and even VMS. > (Boy, does that make me feel old!) > > Maybe an interesting idea to share, but I have intabulated lute music using > Wayne's TAB format with my PDA and folding keyboard on airplane trays on > transatlantic flights. Very simple and functional, therefore. > > Kenneth > > -- > > To get on or off this list see list information at > http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html >
Re: universal music data exchange format
In a message dated 2/18/2005 2:03:17 PM Eastern Standard Time, [EMAIL PROTECTED] writes: Just to set the record straight, my tab format was designed to be e-mailable. This was in the days when there was no internet (just a limited arpanet) and mail was sent from computer to computer via telephones, and mailing binaries was frowned upon. Back when there were as many macs as windows boxes, and lots of versions of unix (no linux!) and even VMS. (Boy, does that make me feel old!) Maybe an interesting idea to share, but I have intabulated lute music using Wayne's TAB format with my PDA and folding keyboard on airplane trays on transatlantic flights. Very simple and functional, therefore. Kenneth -- To get on or off this list see list information at http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html
Re: universal music data exchange format
Also quite compact. I can see how you could do a tab format in XML = (which I work with regularly), but it would be quite a bit more verbose = than Wayne's format and much less easy to edit manually. - Original Message -=20 From: Wayne Cripps<mailto:[EMAIL PROTECTED]>=20 To: lute@cs.dartmouth.edu<mailto:lute@cs.dartmouth.edu>=20 Sent: Friday, February 18, 2005 11:01 AM Subject: Re: universal music data exchange format Just to set the record straight, my tab format was designed to=20 be e-mailable. This was in the days when there was no internet (just a limited arpanet) and mail was sent from computer to computer via telephones, and mailing binaries was frowned=20 upon. Back when there were as many macs as windows boxes,=20 and lots of versions of unix (no linux!) and even VMS.=20 (Boy, does that make me feel old!)=20 For those who understand that, that explains why my program is as it is. Highly portable, not depending on any particular windowing toolkit. Wayne >=20 > Wayne's format is meant to produce nice prints > with his program. Mind you nothing prevents you from writing a = program=20 > that converts tab files to XML first...=20 >=20 >=20 > >On a related note, I've had the idea (for a while now) to get the = tab (Wayne's > >format) for an entire period or composer and run it through a = parser which > >would look for patterns in the music.=20 To get on or off this list see list information at = http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html<http://www.cs.dart= mouth.edu/~wbc/lute-admin/index.html> --
Re: universal music data exchange format
Can anyone help translate from old Spanish the paragraph on the dedillo, on http://cbsr26.ucr.edu/~gls/images/facsimiles/Mudarra/Preface_2.jpg Thanks, Alain To get on or off this list see list information at http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html
Re: universal music data exchange format
It's certainly an interesting idea. Programs have already been written that will write a piece of music in the style of certain composers. I've always thought that if you took out that little 6 note ornamental figure out of Bakfark fantasias there would be precious little left. :-) >On a related note, I've had the idea (for a while now) to get the tab (Wayne's >format) for an entire period or composer and run it through a parser which >would look for patterns in the music. I'd be looking for things like the most >common phrases (length could be variable) in Dowland's music. I've worked with >the tab quite a bit already and think this kind of analysis would be possible. >My original ideas was to generate a "work sheet" for a given program of music >that would help a perform work up music more quickly. The performer could work >through the music making sure the most common passages are under the fingers >first. Kind of a crazy idea, but it shows the potential power of having this >music in a normallized format. > >--- [EMAIL PROTECTED] wrote: > >> "Dr. Marion Ceruti" <[EMAIL PROTECTED]> said: >> >> > >>Tablature and staff notations record different things, tablature records >> finger >> > positions; staff notation records pitch. One CAN translate >>either into the >> >> other, >> > but, SHOULD one? >> > >> > +++Yes. This is why I like TablEdit so much. You input tab and you output >> tab >> > plus staff notation. It is helpful to have both when learning a different >> piece >> > especially if it was written for an instrument with a new tuning. >> >> Sorry to be imprecise, I was thinking of the situation where only ONE set of >> information is recorded, which form should it be? The trouble with forming >> that 'standard' is that one obliges a discarding of information; if only >> pitch is >> recorded one loses information about technique (perhaps also about >> intonation). >> It is not always possible to be certain which playing position the composer >> actually used, even when tablature is evident; only when 'chords' are >> involved is >> it possible to be sure in many cases. >> >> > >>the translation requires knowledge of the tuning of the >> > instrument; is one ALWAYS certain of that? >> > >> > +++Yes. You better >> >> but, do you? Are you certain you have interpreted that german tablature >> correctly? Those glyphs get pretty obscure at times, even when a k ey is >> included, often the glyphs used in the key differ from the ones in the body >> of the >> work. Frequently there will be glyphs unused, and glyphs used but >>once. One >> then >> has to consider the issue of typographical errors. >> >> >> > +++If you are proficient at playing the instrument, usually you will be >> able to >> > select the best way to play a note or a group of notes, among the very few >> > possibilities available. >> >> yes, but, that might be different for you than it was for the composer, and >> perhaps when the composer indicates a particular position there is >>some tonal >> >> reason for it; or perhaps it due to faulty memory that the uncommonly played >> piece >> gets set down in one way when it would have been (or was) originally played >> much >> differently. >> >> >> >> To get on or off this list see list information at >> http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html >> -- Ed Durbrow Saitama, Japan http://www9.plala.or.jp/edurbrow/
Re: universal music data exchange format
Just to set the record straight, my tab format was designed to be e-mailable. This was in the days when there was no internet (just a limited arpanet) and mail was sent from computer to computer via telephones, and mailing binaries was frowned upon. Back when there were as many macs as windows boxes, and lots of versions of unix (no linux!) and even VMS. (Boy, does that make me feel old!) For those who understand that, that explains why my program is as it is. Highly portable, not depending on any particular windowing toolkit. Wayne > > Wayne's format is meant to produce nice prints > with his program. Mind you nothing prevents you from writing a program > that converts tab files to XML first... > > > >On a related note, I've had the idea (for a while now) to get the tab > >(Wayne's > >format) for an entire period or composer and run it through a parser which > >would look for patterns in the music. To get on or off this list see list information at http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html
Re: universal music data exchange format
XML would be much more efficient for that and many other purposes because of all the parsing tools that are being developed for that format, and because it is a structured format that is meant to do precisely that sort of manipulation. Wayne's format is meant to produce nice prints with his program. Mind you nothing prevents you from writing a program that converts tab files to XML first... But you would probably find that a lot of manual editing is necessary for consistency across a large pool of documents and that would defeat the purpose, I think. Alain Christopher Schaub wrote: >On a related note, I've had the idea (for a while now) to get the tab (Wayne's >format) for an entire period or composer and run it through a parser which >would look for patterns in the music. I'd be looking for things like the most >common phrases (length could be variable) in Dowland's music. I've worked with >the tab quite a bit already and think this kind of analysis would be possible. >My original ideas was to generate a "work sheet" for a given program of music >that would help a perform work up music more quickly. The performer could work >through the music making sure the most common passages are under the fingers >first. Kind of a crazy idea, but it shows the potential power of having this >music in a normallized format. > >--- [EMAIL PROTECTED] wrote: > > > >>"Dr. Marion Ceruti" <[EMAIL PROTECTED]> said: >> >> >> >Tablature and staff notations record different things, tablature records > > >>finger >> >> >>>positions; staff notation records pitch. One CAN translate either into the >>> >>> >>other, >> >> >>>but, SHOULD one? >>> >>>+++Yes. This is why I like TablEdit so much. You input tab and you output >>> >>> >>tab >> >> >>>plus staff notation. It is helpful to have both when learning a different >>> >>> >>piece >> >> >>>especially if it was written for an instrument with a new tuning. >>> >>> >>Sorry to be imprecise, I was thinking of the situation where only ONE set of >>information is recorded, which form should it be? The trouble with forming >>that 'standard' is that one obliges a discarding of information; if only >>pitch is >>recorded one loses information about technique (perhaps also about >>intonation). >>It is not always possible to be certain which playing position the composer >>actually used, even when tablature is evident; only when 'chords' are >>involved is >>it possible to be sure in many cases. >> >> >> >the translation requires knowledge of the tuning of the > > >>>instrument; is one ALWAYS certain of that? >>> >>>+++Yes. You better >>> >>> >>but, do you? Are you certain you have interpreted that german tablature >>correctly? Those glyphs get pretty obscure at times, even when a k ey is >>included, often the glyphs used in the key differ from the ones in the body >>of the >>work. Frequently there will be glyphs unused, and glyphs used but once. One >>then >>has to consider the issue of typographical errors. >> >> >> >> >>>+++If you are proficient at playing the instrument, usually you will be >>> >>> >>able to >> >> >>>select the best way to play a note or a group of notes, among the very few >>>possibilities available. >>> >>> >>yes, but, that might be different for you than it was for the composer, and >>perhaps when the composer indicates a particular position there is some tonal >> >>reason for it; or perhaps it due to faulty memory that the uncommonly played >>piece >>gets set down in one way when it would have been (or was) originally played >>much >>differently. >> >> >> >>To get on or off this list see list information at >>http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html >> >> >> > > > > >
Re: universal music data exchange format
On a related note, I've had the idea (for a while now) to get the tab (Wayne's format) for an entire period or composer and run it through a parser which would look for patterns in the music. I'd be looking for things like the most common phrases (length could be variable) in Dowland's music. I've worked with the tab quite a bit already and think this kind of analysis would be possible. My original ideas was to generate a "work sheet" for a given program of music that would help a perform work up music more quickly. The performer could work through the music making sure the most common passages are under the fingers first. Kind of a crazy idea, but it shows the potential power of having this music in a normallized format. --- [EMAIL PROTECTED] wrote: > "Dr. Marion Ceruti" <[EMAIL PROTECTED]> said: > > > >>Tablature and staff notations record different things, tablature records > finger > > positions; staff notation records pitch. One CAN translate either into the > > other, > > but, SHOULD one? > > > > +++Yes. This is why I like TablEdit so much. You input tab and you output > tab > > plus staff notation. It is helpful to have both when learning a different > piece > > especially if it was written for an instrument with a new tuning. > > Sorry to be imprecise, I was thinking of the situation where only ONE set of > information is recorded, which form should it be? The trouble with forming > that 'standard' is that one obliges a discarding of information; if only > pitch is > recorded one loses information about technique (perhaps also about > intonation). > It is not always possible to be certain which playing position the composer > actually used, even when tablature is evident; only when 'chords' are > involved is > it possible to be sure in many cases. > > > >>the translation requires knowledge of the tuning of the > > instrument; is one ALWAYS certain of that? > > > > +++Yes. You better > > but, do you? Are you certain you have interpreted that german tablature > correctly? Those glyphs get pretty obscure at times, even when a k ey is > included, often the glyphs used in the key differ from the ones in the body > of the > work. Frequently there will be glyphs unused, and glyphs used but once. One > then > has to consider the issue of typographical errors. > > > > +++If you are proficient at playing the instrument, usually you will be > able to > > select the best way to play a note or a group of notes, among the very few > > possibilities available. > > yes, but, that might be different for you than it was for the composer, and > perhaps when the composer indicates a particular position there is some tonal > > reason for it; or perhaps it due to faulty memory that the uncommonly played > piece > gets set down in one way when it would have been (or was) originally played > much > differently. > > > > To get on or off this list see list information at > http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html >
Re: universal music data exchange format
"Dr. Marion Ceruti" <[EMAIL PROTECTED]> said: > >>Tablature and staff notations record different things, tablature records finger > positions; staff notation records pitch. One CAN translate either into the other, > but, SHOULD one? > > +++Yes. This is why I like TablEdit so much. You input tab and you output tab > plus staff notation. It is helpful to have both when learning a different > piece > especially if it was written for an instrument with a new tuning. Sorry to be imprecise, I was thinking of the situation where only ONE set of information is recorded, which form should it be? The trouble with forming that 'standard' is that one obliges a discarding of information; if only pitch is recorded one loses information about technique (perhaps also about intonation). It is not always possible to be certain which playing position the composer actually used, even when tablature is evident; only when 'chords' are involved is it possible to be sure in many cases. > >>the translation requires knowledge of the tuning of the > instrument; is one ALWAYS certain of that? > > +++Yes. You better but, do you? Are you certain you have interpreted that german tablature correctly? Those glyphs get pretty obscure at times, even when a k ey is included, often the glyphs used in the key differ from the ones in the body of the work. Frequently there will be glyphs unused, and glyphs used but once. One then has to consider the issue of typographical errors. > +++If you are proficient at playing the instrument, usually you will be able > to > select the best way to play a note or a group of notes, among the very few > possibilities available. yes, but, that might be different for you than it was for the composer, and perhaps when the composer indicates a particular position there is some tonal reason for it; or perhaps it due to faulty memory that the uncommonly played piece gets set down in one way when it would have been (or was) originally played much differently. To get on or off this list see list information at http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html
Re: universal music data exchange format
-Original Message- From: [EMAIL PROTECTED] Sent: Feb 15, 2005 11:23 AM To: lute@cs.dartmouth.edu Subject: universal music data exchange format Jon Murphy <[EMAIL PROTECTED]> said: > Speaking specifically of music the ideal would be a protocol that could > transmit without regard to notation. The absolute notes themselves. would it? I wonder. +++If everyone could read minds and transfer musical ideas without media, think it would be wonderful to do away with all notation and just deal with tones. However, this is totally impractical becuase we want a better, less ambiguous way to transmit musical ideas. >>Consider natural language for a moment. The several writing systems in use modernly and historically have numerous flaws relating to imprecision of pronunciation. ++This situation is complicated by the fact that in different regions of the same country, people use different pronunciations for the same words. Which one is best? Take Chinese for example. The writing is the same among the different dialects, but for the pronunciation is different. >>English is quite varied in the sound of its vowels, enough so to be a major source of confusion to non-native speakers (to the point of making for songs and puns). +++Pronunciation is too hard to encode in a written language unless you want to make it very precise, very expressive and too complicated to learn. I cannot think of one language in which this has succeeded. Even if you introduce a pronunciation code, there will be debates on how to interpret the code. >>Linguists have their own notations when recording suonds precisely, but these are sometimes TOO precise; one wouldnt expect a peom to be set down in IPA, especially one that depended on aural ambiguity for some of its art. +++Even if you could pick a precise pronunication, some people would not like it because it would not be "their" pronunciation. >>Tablature and staff notations record different things, tablature records >>finger positions; staff notation records pitch. One CAN translate either into the other, but, SHOULD one? +++Yes. This is why I like TablEdit so much. You input tab and you output tab plus staff notation. It is helpful to have both when learning a different piece especially if it was written for an instrument with a new tuning. >>the translation requires knowledge of the tuning of the instrument; is one ALWAYS certain of that? +++Yes. You better know something as fundamental as the tuning of the instrument. If not, you really cannot play the piece correctly because, like modern atonal music that sounds like @#$%&*, it will sound aweful if you follow strict tab using the wrong tuning, and we try to avoid as much as possible anything that sounds aweful. When an instrument has multiple ways of playing the same note (2 or 3 on guitar, lute and cittern, there is potential ambiguity that is best avoided by use of tablature. +++If you are proficient at playing the instrument, usually you will be able to select the best way to play a note or a group of notes, among the very few possibilities available. Usually, one way (or two at most) will emerge as being possible to do given the notes that come before and after it . The other ways will seem too awkward. Even so, I like to have the precision and clarity of tab along side of the staff notation because I memorize music and I am not as good at sight singing tab mentally as I am with staff notation. So it is best to have both. Cheers, Marion To get on or off this list see list information at http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html
