From andrew.hankinson at mail.mcgill.ca Sun Nov 20 20:31:29 2016 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sun, 20 Nov 2016 19:31:29 +0000 Subject: [mei-neumes-ig] =?utf-8?q?Minutes_of_Meeting=3A_T=C3=BCbingen=2C_?= =?utf-8?q?19_November?= Message-ID: <60EC3358-15BF-4138-B87E-983BC3BE72EF@mail.mcgill.ca> Hello all, Here are the minutes of the meeting we had yesterday in Tübingen. Attendees, please reply and comment if there are amendments to be made. Cheers, -Andrew ------ MEI Neumes Interest Group Meeting : 19 November 2016, Tübingen, Germany Present: - Andrew Hankinson (U. Oxford) - Kate Helsen (U. Western Ontario) - Elaine Hild (U. Würtemberg) - Stefan Morent (U. Tübingen) - Jason Stoessel (U. New England) - Thomas Weber (Notengrafik Berlin) - Werner Wolff (Notengrafik Berlin) A meeting of some members of the MEI Neumes Interest Group took place at the University of Tübingen, after the "Digital Methods in Musicology Winterschool." The meeting started at 18:00. Stefan opened the meeting with a reminder of the first meeting of the SIG at the Music Encoding Conference in Mainz in 2013. Andrew mentioned that the MEI Neumes SIG mailing list was now functioning, and encouraged the members present to sign up and use it as a discussion forum for the group, so that everyone could be 'in the loop.' Andrew reviewed some of the recent discussions that had been taking place in various forums since the last meeting. Notably, he acknowledged the work of Emma Hornby's team at Bristol in developing their contour-based description of individual neumes, and that this was the basis of the current discussions in individual neume descriptions. It was agreed that this was a better way forward than the current requirement to 'name' individual neumes. Andrew mentioned that it would still be possible to assign a name to a neume, but that this would be handled through a reference to an item in a taxonomy, likely held in the MEI header of a given file. Andrew discussed the structure of a neume element, and the necessary separation between a "pitch" and a "component". A component was described as an individual pitch-carrying element, although the exact pitch may not be known (e.g., Hartker). It was also acknowledged that one of the reasons for the existence of a component separate from a 'note' element was the need to describe the connections between the individual components. Jason clarified that adopting component would not have an impact on the data he already had with John Stinson's corpus. Jason asked whether 'component' was over-engineering for pitched repertoires, since the contour was implicitly carried on 'note' if a pitch name was present. Andrew presented two arguments: one, that it was over-engineering and that it might be sufficient to simply contain 'note' within 'neume', and two, that it would be better for software developers if we could expect a consistent structure within neume, and that component was necessary to capture relationship between two components. After some discussion it was agreed to require 'component' as a container for 'note', but that it could be minimally described. Thomas asked if we could 'overload' the note element to describe the contour, but Andrew mentioned that having the separation between note and component was useful, since we want to describe the connection between the individual pitches, and that 'component' was a useful abstraction. Elaine mentioned that the word 'component' was not present in standard literature about neume structure. Andrew acknowledged this, and that it was not set in stone should a more suitable name be offered. Werner raised a question of whether we were describing a 'pitch' or a 'pen stroke' within a neume. After some discussion we agreed that it was a pitch, since pen strokes would differ between notation styles. THis would mean cross-style comparison would be more difficult. Kate presented the table that she and Inga had been working on, and described their plan for how individual neumes might be identified by unique combinations of individual components. The "@modification", "@connection", and "@liquesence" attributes were proposed for the 'component' element. Andrew clarified that the "relation to previous" and "relation to next" attributes with values of 'H', 'L', or 'N' were necessary to be carried on the 'neume' element. Andrew moved the discussion to the question of textual representation, and acknowledged that the current method of organization in MEI Neumes (syllable-first) came from Stefan's work. Andrew presented two options: one, that we keep the syllable-first organization since it could be argued that a neume was a 'property' or 'sonification' of that syllable, and this organization represented that subordinate relationship in the XML structure. The second option was that we separate the neumes and text into 'streams', where syllables are related to individual neumes by the use of the MEI XML ID linking pattern. This would better represent the separation of the 'streams' (Stefan clarified this terminology): textual streams, and musical streams on the staff. Jason asked where the text stream would be stored, as this would have an impact on manual "one-pass" encoding. Andrew suggested that it may be stored separately, similar to the 'facsimile' and 'recording' streams already present, but no decisions were made about this. We considered questions of contrafact and multiple text underlays. Thomas clarified that it would be possible to have a n-1 relationship (that is, the same neume could carry two texts). A discussion of how to treat oriscus, quilisma, and strophici was held, and whether they would constitue their own 'neume' or that they would be properties of a single component. Kate showed how she and Inga handled this in their table, assigning an oriscus to a particular combination of component attributes, while Thomas and Elaine said that they used an attribute on the neume to describe it. It was agreed that further experimentation and sample encodings would help to clarify the best way to capture this information. Andrew brought up the need to capture the notation style: "square", "aquitanian", "old hispanic", etc. It was agreed that there was little consensus on how these styles would be named, and that the possible values for these names were endless. Nevertheless, it was agreed that some information about this would be necessary to capture. Andrew suggested incorporating URIs as identifiers for notation styles, and it was generally agreed that this was a good idea, but that the possibility of capturing a human-readable name would still be convenient. A discussion of how to treat rubrics was held. Thomas and Elaine presented a case for making a new element, 'rubric', that could be handled as part of the musical structure since it typically contains performance information (similar to textual performance instructions in CMN, i.e., 'andante'). Jason concurred that a dedicated element for capturing rubrics was an attractive idea. We decided to further explore this idea at a later date. Andrew concluded the meeting with two comments: One, that a 'test set' for neume encodings should be established, with samples drawn from various repertoires in order to shake out the details of the encoding, and two, that as an 'official' interest group we were entitled to a repository on the MEI GitHub, and that he could set this up after checking with the board. The meeting ended at 20:00. ---- AH ---- From ichiro.fujinaga at mcgill.ca Sun Nov 20 21:01:12 2016 From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.) Date: Sun, 20 Nov 2016 20:01:12 +0000 Subject: [mei-neumes-ig] =?utf-8?q?Minutes_of_Meeting=3A_T=C3=BCbingen=2C?= =?utf-8?q?_19_November?= In-Reply-To: <21782_1479670346_5831FA4A_21782_193_1_c00e15d1cb1a41869d6bfd21f1bb7627@BY1PR03MB1481.namprd03.prod.outlook.com> References: <21782_1479670346_5831FA4A_21782_193_1_c00e15d1cb1a41869d6bfd21f1bb7627@BY1PR03MB1481.namprd03.prod.outlook.com> Message-ID: Sounds like you had a very productive meeting! Thank you, Andrew, for taking and posting the minutes. As a member of the MEI Board, I’ll ask if you can set up a repository on the MEI GitHub. Ichiro > On Nov 20, 2016, at 2:31 PM, Andrew Hankinson wrote: > > Hello all, > > Here are the minutes of the meeting we had yesterday in Tübingen. Attendees, please reply and comment if there are amendments to be made. > > Cheers, > -Andrew > > ------ > > MEI Neumes Interest Group Meeting : 19 November 2016, Tübingen, Germany > > Present: > - Andrew Hankinson (U. Oxford) > - Kate Helsen (U. Western Ontario) > - Elaine Hild (U. Würtemberg) > - Stefan Morent (U. Tübingen) > - Jason Stoessel (U. New England) > - Thomas Weber (Notengrafik Berlin) > - Werner Wolff (Notengrafik Berlin) > > A meeting of some members of the MEI Neumes Interest Group took place at the University of Tübingen, after the "Digital Methods in Musicology Winterschool." The meeting started at 18:00. > > Stefan opened the meeting with a reminder of the first meeting of the SIG at the Music Encoding Conference in Mainz in 2013. Andrew mentioned that the MEI Neumes SIG mailing list was now functioning, and encouraged the members present to sign up and use it as a discussion forum for the group, so that everyone could be 'in the loop.' > > Andrew reviewed some of the recent discussions that had been taking place in various forums since the last meeting. Notably, he acknowledged the work of Emma Hornby's team at Bristol in developing their contour-based description of individual neumes, and that this was the basis of the current discussions in individual neume descriptions. It was agreed that this was a better way forward than the current requirement to 'name' individual neumes. Andrew mentioned that it would still be possible to assign a name to a neume, but that this would be handled through a reference to an item in a taxonomy, likely held in the MEI header of a given file. > > Andrew discussed the structure of a neume element, and the necessary separation between a "pitch" and a "component". A component was described as an individual pitch-carrying element, although the exact pitch may not be known (e.g., Hartker). It was also acknowledged that one of the reasons for the existence of a component separate from a 'note' element was the need to describe the connections between the individual components. Jason clarified that adopting component would not have an impact on the data he already had with John Stinson's corpus. > > Jason asked whether 'component' was over-engineering for pitched repertoires, since the contour was implicitly carried on 'note' if a pitch name was present. Andrew presented two arguments: one, that it was over-engineering and that it might be sufficient to simply contain 'note' within 'neume', and two, that it would be better for software developers if we could expect a consistent structure within neume, and that component was necessary to capture relationship between two components. After some discussion it was agreed to require 'component' as a container for 'note', but that it could be minimally described. > > Thomas asked if we could 'overload' the note element to describe the contour, but Andrew mentioned that having the separation between note and component was useful, since we want to describe the connection between the individual pitches, and that 'component' was a useful abstraction. Elaine mentioned that the word 'component' was not present in standard literature about neume structure. Andrew acknowledged this, and that it was not set in stone should a more suitable name be offered. > > Werner raised a question of whether we were describing a 'pitch' or a 'pen stroke' within a neume. After some discussion we agreed that it was a pitch, since pen strokes would differ between notation styles. THis would mean cross-style comparison would be more difficult. > > Kate presented the table that she and Inga had been working on, and described their plan for how individual neumes might be identified by unique combinations of individual components. The "@modification", "@connection", and "@liquesence" attributes were proposed for the 'component' element. Andrew clarified that the "relation to previous" and "relation to next" attributes with values of 'H', 'L', or 'N' were necessary to be carried on the 'neume' element. > > Andrew moved the discussion to the question of textual representation, and acknowledged that the current method of organization in MEI Neumes (syllable-first) came from Stefan's work. Andrew presented two options: one, that we keep the syllable-first organization since it could be argued that a neume was a 'property' or 'sonification' of that syllable, and this organization represented that subordinate relationship in the XML structure. The second option was that we separate the neumes and text into 'streams', where syllables are related to individual neumes by the use of the MEI XML ID linking pattern. This would better represent the separation of the 'streams' (Stefan clarified this terminology): textual streams, and musical streams on the staff. Jason asked where the text stream would be stored, as this would have an impact on manual "one-pass" encoding. Andrew suggested that it may be stored separately, similar to the 'facsimile' and 'recording' streams already present, but no decisions were made about this. > > We considered questions of contrafact and multiple text underlays. Thomas clarified that it would be possible to have a n-1 relationship (that is, the same neume could carry two texts). > > A discussion of how to treat oriscus, quilisma, and strophici was held, and whether they would constitue their own 'neume' or that they would be properties of a single component. Kate showed how she and Inga handled this in their table, assigning an oriscus to a particular combination of component attributes, while Thomas and Elaine said that they used an attribute on the neume to describe it. It was agreed that further experimentation and sample encodings would help to clarify the best way to capture this information. > > Andrew brought up the need to capture the notation style: "square", "aquitanian", "old hispanic", etc. It was agreed that there was little consensus on how these styles would be named, and that the possible values for these names were endless. Nevertheless, it was agreed that some information about this would be necessary to capture. Andrew suggested incorporating URIs as identifiers for notation styles, and it was generally agreed that this was a good idea, but that the possibility of capturing a human-readable name would still be convenient. > > A discussion of how to treat rubrics was held. Thomas and Elaine presented a case for making a new element, 'rubric', that could be handled as part of the musical structure since it typically contains performance information (similar to textual performance instructions in CMN, i.e., 'andante'). Jason concurred that a dedicated element for capturing rubrics was an attractive idea. We decided to further explore this idea at a later date. > > Andrew concluded the meeting with two comments: One, that a 'test set' for neume encodings should be established, with samples drawn from various repertoires in order to shake out the details of the encoding, and two, that as an 'official' interest group we were entitled to a repository on the MEI GitHub, and that he could set this up after checking with the board. > > The meeting ended at 20:00. > > ---- AH ---- > _______________________________________________ > mei-neumes-ig mailing list > mei-neumes-ig at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig > From inga.behrendt at uni-tuebingen.de Tue Nov 22 14:09:22 2016 From: inga.behrendt at uni-tuebingen.de (Inga Behrendt) Date: Tue, 22 Nov 2016 14:09:22 +0100 Subject: [mei-neumes-ig] =?utf-8?q?Minutes_of_Meeting=3A_T=C3=BCbingen=2C?= =?utf-8?q?_19_November?= In-Reply-To: <60EC3358-15BF-4138-B87E-983BC3BE72EF@mail.mcgill.ca> References: <60EC3358-15BF-4138-B87E-983BC3BE72EF@mail.mcgill.ca> Message-ID: <002601d244c1$a4aa3240$edfe96c0$@uni-tuebingen.de> Dear Andrew, thank you for this great minutes! I learned a lot while reading them. Stefan Morent and I just talked about several things; it was very good for our institute that the Winterschool took place. Now, also the colleagues that haven´t been in touch with MEI are curious and want to get to know more. Perfect! Hopefully you had a good trip back, Andrew, and also all the other members of the MEI Neumes Interest Group! Best wishes, Inga -----Ursprüngliche Nachricht----- Von: mei-neumes-ig [mailto:mei-neumes-ig-bounces at lists.uni-paderborn.de] Im Auftrag von Andrew Hankinson Gesendet: Sonntag, 20. November 2016 20:31 An: Neumes Interest Group of the Music Encoding Initiative Betreff: [mei-neumes-ig] Minutes of Meeting: Tübingen, 19 November Hello all, Here are the minutes of the meeting we had yesterday in Tübingen. Attendees, please reply and comment if there are amendments to be made. Cheers, -Andrew ------ MEI Neumes Interest Group Meeting : 19 November 2016, Tübingen, Germany Present: - Andrew Hankinson (U. Oxford) - Kate Helsen (U. Western Ontario) - Elaine Hild (U. Würtemberg) - Stefan Morent (U. Tübingen) - Jason Stoessel (U. New England) - Thomas Weber (Notengrafik Berlin) - Werner Wolff (Notengrafik Berlin) A meeting of some members of the MEI Neumes Interest Group took place at the University of Tübingen, after the "Digital Methods in Musicology Winterschool." The meeting started at 18:00. Stefan opened the meeting with a reminder of the first meeting of the SIG at the Music Encoding Conference in Mainz in 2013. Andrew mentioned that the MEI Neumes SIG mailing list was now functioning, and encouraged the members present to sign up and use it as a discussion forum for the group, so that everyone could be 'in the loop.' Andrew reviewed some of the recent discussions that had been taking place in various forums since the last meeting. Notably, he acknowledged the work of Emma Hornby's team at Bristol in developing their contour-based description of individual neumes, and that this was the basis of the current discussions in individual neume descriptions. It was agreed that this was a better way forward than the current requirement to 'name' individual neumes. Andrew mentioned that it would still be possible to assign a name to a neume, but that this would be handled through a reference to an item in a taxonomy, likely held in the MEI header of a given file. Andrew discussed the structure of a neume element, and the necessary separation between a "pitch" and a "component". A component was described as an individual pitch-carrying element, although the exact pitch may not be known (e.g., Hartker). It was also acknowledged that one of the reasons for the existence of a component separate from a 'note' element was the need to describe the connections between the individual components. Jason clarified that adopting component would not have an impact on the data he already had with John Stinson's corpus. Jason asked whether 'component' was over-engineering for pitched repertoires, since the contour was implicitly carried on 'note' if a pitch name was present. Andrew presented two arguments: one, that it was over-engineering and that it might be sufficient to simply contain 'note' within 'neume', and two, that it would be better for software developers if we could expect a consistent structure within neume, and that component was necessary to capture relationship between two components. After some discussion it was agreed to require 'component' as a container for 'note', but that it could be minimally described. Thomas asked if we could 'overload' the note element to describe the contour, but Andrew mentioned that having the separation between note and component was useful, since we want to describe the connection between the individual pitches, and that 'component' was a useful abstraction. Elaine mentioned that the word 'component' was not present in standard literature about neume structure. Andrew acknowledged this, and that it was not set in stone should a more suitable name be offered. Werner raised a question of whether we were describing a 'pitch' or a 'pen stroke' within a neume. After some discussion we agreed that it was a pitch, since pen strokes would differ between notation styles. THis would mean cross-style comparison would be more difficult. Kate presented the table that she and Inga had been working on, and described their plan for how individual neumes might be identified by unique combinations of individual components. The "@modification", "@connection", and "@liquesence" attributes were proposed for the 'component' element. Andrew clarified that the "relation to previous" and "relation to next" attributes with values of 'H', 'L', or 'N' were necessary to be carried on the 'neume' element. Andrew moved the discussion to the question of textual representation, and acknowledged that the current method of organization in MEI Neumes (syllable-first) came from Stefan's work. Andrew presented two options: one, that we keep the syllable-first organization since it could be argued that a neume was a 'property' or 'sonification' of that syllable, and this organization represented that subordinate relationship in the XML structure. The second option was that we separate the neumes and text into 'streams', where syllables are related to individual neumes by the use of the MEI XML ID linking pattern. This would better represent the separation of the 'streams' (Stefan clarified this terminology): textual streams, and musical streams on the staff. Jason asked where the text stream would be stored, as this would have an impact on manual "one-pass" encoding. Andrew suggested that it may be stored separately, similar to the 'facsimile' and 'recording' streams already present, but no decisions were made about this. We considered questions of contrafact and multiple text underlays. Thomas clarified that it would be possible to have a n-1 relationship (that is, the same neume could carry two texts). A discussion of how to treat oriscus, quilisma, and strophici was held, and whether they would constitue their own 'neume' or that they would be properties of a single component. Kate showed how she and Inga handled this in their table, assigning an oriscus to a particular combination of component attributes, while Thomas and Elaine said that they used an attribute on the neume to describe it. It was agreed that further experimentation and sample encodings would help to clarify the best way to capture this information. Andrew brought up the need to capture the notation style: "square", "aquitanian", "old hispanic", etc. It was agreed that there was little consensus on how these styles would be named, and that the possible values for these names were endless. Nevertheless, it was agreed that some information about this would be necessary to capture. Andrew suggested incorporating URIs as identifiers for notation styles, and it was generally agreed that this was a good idea, but that the possibility of capturing a human-readable name would still be convenient. A discussion of how to treat rubrics was held. Thomas and Elaine presented a case for making a new element, 'rubric', that could be handled as part of the musical structure since it typically contains performance information (similar to textual performance instructions in CMN, i.e., 'andante'). Jason concurred that a dedicated element for capturing rubrics was an attractive idea. We decided to further explore this idea at a later date. Andrew concluded the meeting with two comments: One, that a 'test set' for neume encodings should be established, with samples drawn from various repertoires in order to shake out the details of the encoding, and two, that as an 'official' interest group we were entitled to a repository on the MEI GitHub, and that he could set this up after checking with the board. The meeting ended at 20:00. ---- AH ---- _______________________________________________ mei-neumes-ig mailing list mei-neumes-ig at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig From thomas.weber at notengrafik.com Wed Nov 23 16:19:06 2016 From: thomas.weber at notengrafik.com (Thomas Weber) Date: Wed, 23 Nov 2016 16:19:06 +0100 Subject: [mei-neumes-ig] =?utf-8?q?Minutes_of_Meeting=3A_T=C3=BCbingen=2C?= =?utf-8?q?_19_November?= In-Reply-To: <60EC3358-15BF-4138-B87E-983BC3BE72EF@mail.mcgill.ca> References: <60EC3358-15BF-4138-B87E-983BC3BE72EF@mail.mcgill.ca> Message-ID: Many thanks, Andrew! Just some short corrections: Am 20.11.2016 um 20:31 schrieb Andrew Hankinson: > - Elaine Hild (U. Würtemberg) That's "Würzburg". > A discussion of how to treat rubrics was held. Thomas and Elaine presented a case for making a new element, 'rubric', that could be handled as part of the musical structure since it typically contains performance information (similar to textual performance instructions in CMN, i.e., 'andante'). Actually, rubrics are used for a much wider range of things. To cite the NeumesXML[1] documentation "labels for feast days, offices and masses; types of pieces; verses" In order to not lose momentum, I'd like to ignite a discussion about how exactly to proceed. We have two nicely separable fields - one being transforming the neume description approach presented by Inga and Kate into XML, the other being separation of text and music layers. The incorporation of rubrics should be made part of the latter, I think. In my understanding, rubrics can be thought of as just other elements that occur in the linear flow of text, as opposed to tempo text, stage directions or the like in CMN, which are on different layers than lyrics. In NeumesXML[2], is used interspersedly with . It also has a element (if you click through "/NeumesXML/transcription_part/transcription/spoken_text" on the funky 90ies style website[3]). Is there any value in distinguishing between "general" rubrics and spoken text, e.g. for liturgic plays? I'd next want to pick one or two short example chants from the Corpus monodicum data and draft an encoding of the music that would suit our needs, based on how I understood the new encoding might work. I'd leave the text problem alone for now. For the very first drafts, I think sharing via e-mail might be preferable over a branch or folder for drafts on our fresh Github[4] repo. Best Thomas [1] http://www.scribeserver.com/NEUMES/neumesxml_tree/tree_detail_west/rubric.htm [2] http://www.scribeserver.com/NEUMES/xml/transcriptions/NeumesExample.xml [3] http://www.scribeserver.com/NEUMES/neumesxml_tree/neumesxml_tree_frames_west.htm [4] https://github.com/music-encoding/neume-ig/wiki -- Notengrafik Berlin GmbH HRB 15007 UstID: DE 289234097 Geschäftsführer: Thomas Weber und Werner J. Wolff fon: +49 30 220661685 Leuschnerdamm 13 10999 Berlin notengrafik.com From stefan.morent at uni-tuebingen.de Mon Nov 28 12:25:16 2016 From: stefan.morent at uni-tuebingen.de (Prof. Dr. Morent) Date: Mon, 28 Nov 2016 12:25:16 +0100 Subject: [mei-neumes-ig] =?utf-8?q?Minutes_of_Meeting=3A_T=C3=BCbingen=2C?= =?utf-8?q?_19_November?= In-Reply-To: References: <60EC3358-15BF-4138-B87E-983BC3BE72EF@mail.mcgill.ca> Message-ID: <20161128122516.Horde.vVPUNjEmEKzkcILo9DfX6Oj@webmail.uni-tuebingen.de> Dear all, as discussed in Tübingen and proposed by Thomas Weber in his last message I would find it a good idea to run some test cases of various neumed repertories, to see how the transformed MEI-neumes-module as we have it in mind would fit their needs. I could provide examples from the TüBingen-project, Hildegard songs already encoded in the "old" MEI neumes-module (German neumes on lines). best Stefan ----- Nachricht von Thomas Weber --------- Datum: Wed, 23 Nov 2016 16:19:06 +0100 Von: Thomas Weber Antwort an: Neumes Interest Group of the Music Encoding Initiative Betreff: Re: [mei-neumes-ig] Minutes of Meeting: Tübingen, 19 November An: Neumes Interest Group of the Music Encoding Initiative Cc: ngb at notengrafik.com > Many thanks, Andrew! Just some short corrections: > > > Am 20.11.2016 um 20:31 schrieb Andrew Hankinson: >> - Elaine Hild (U. Würtemberg) > > > That's "Würzburg". > > >> A discussion of how to treat rubrics was held. Thomas and Elaine >> presented a case for making a new element, 'rubric', that could be >> handled as part of the musical structure since it typically >> contains performance information (similar to textual performance >> instructions in CMN, i.e., 'andante'). > > > Actually, rubrics are used for a much wider range of things. To > cite the NeumesXML[1] documentation "labels for feast days, offices > and masses; types of pieces; verses" > > > In order to not lose momentum, I'd like to ignite a discussion about > how exactly to proceed. We have two nicely separable fields - one > being transforming the neume description approach presented by Inga > and Kate into XML, the other being separation of text and music > layers. The incorporation of rubrics should be made part of the > latter, I think. In my understanding, rubrics can be thought of as > just other elements that occur in the linear flow of text, as > opposed to tempo text, stage directions or the like in CMN, which > are on different layers than lyrics. > > In NeumesXML[2], is used interspersedly with > . It also has a element (if you > click through > "/NeumesXML/transcription_part/transcription/spoken_text" on the > funky 90ies style website[3]). Is there any value in distinguishing > between "general" rubrics and spoken text, e.g. for liturgic plays? > > I'd next want to pick one or two short example chants from the > Corpus monodicum data and draft an encoding of the music that would > suit our needs, based on how I understood the new encoding might > work. I'd leave the text problem alone for now. For the very first > drafts, I think sharing via e-mail might be preferable over a branch > or folder for drafts on our fresh Github[4] repo. > > > Best > Thomas > > > > [1] > http://www.scribeserver.com/NEUMES/neumesxml_tree/tree_detail_west/rubric.htm > [2] http://www.scribeserver.com/NEUMES/xml/transcriptions/NeumesExample.xml > [3] > http://www.scribeserver.com/NEUMES/neumesxml_tree/neumesxml_tree_frames_west.htm > [4] https://github.com/music-encoding/neume-ig/wiki > > > -- > > Notengrafik Berlin GmbH > HRB 15007 > > UstID: DE 289234097 > Geschäftsführer: > Thomas Weber und Werner J. Wolff > > fon: +49 30 220661685 > > Leuschnerdamm 13 > 10999 Berlin > > notengrafik.com > > > _______________________________________________ > mei-neumes-ig mailing list > mei-neumes-ig at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig ----- Ende der Nachricht von Thomas Weber -----