[MEI-L] Encoding staff positions

Tue Feb 8 14:24:48 CET 2011

Hi Johannes,

On Tue, Feb 8, 2011 at 9:36 AM, Johannes Kepper <kepper at edirom.de> wrote:
> Hi Laurent,
>
>
> Am 08.02.2011 um 09:15 schrieb Laurent Pugin:
>
>> Hi,
>>
>> yes, I agree that the cases described by the genetic encoding group
>> are rather extreme ones for which the best thing to do for music would
>> probably be to use MEI within TEI together with the GE module.
>
> I would even try to integrate it without TEI in the middle, but that's something for a long and lonely evening…
>

Yes, you are right.

>>
>> It should not preclude us to improve MEI itself for the 80% of the
>> situations, and I also agree the it can be a 'small' solution. My
>> impression is that with <pb> and <sb> becoming <page> and <system>, we
>> would have pretty much everything we need for the new hierarchy.
>> Inside it, the sub-tree is likely to stay the same, but some
>> containing elements (such as <measure>) would definitely have to
>> become milestones. That is the big question, as Perry said, but if
>> they are not too many of them, I see it as a small solution that would
>> do it.
>
> You already can use <barline> instead of <measure>. Not sure if this buys you anything, but maybe it's worth to think over.
>

Thanks for the tip. I forgot about that one, it should do it.

>>
>> In my opinion, it can be useful to capture the original source at the
>> very beginning of an editorial process, but it could also be useful at
>> the end of the process. If we think of the case where MEI is used to
>> encode a new edition, this feature could also make it easier to encode
>> its layout and to represent it. If we have an orchestra score with,
>> let's say, hundreds of pages, turning a page would require every time
>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>> know software issues are not the starting point when defining an
>> encoding, but this is seriously not optimal. Why shouldn't I have to
>> option to have the encoding in a page-oriented way when the edition
>> reached a publishing stage? And maybe to add some more detailed layout
>> information for making it easier to read? I don't know, it is just one
>> way I see to use MEI.
>>
>
> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>
>

Your solution is an excellent one to get both at the same time, which
is of course ideal. It is a elegant workaround to keep both in memory
in order to avoid to have to re-parse the tree every single time you
need to access something that is spread over several branches in the
hierarchy. But if you think of a large repository of MEI files from
which you want to quickly access specific pages over the web, you
would need another solution. Something built in MEI would be nice.

Your case also illustrates the fact that, in many applications, having
access to both representations is necessary. You choose as main
structure the one that is the most relevant for you. In some cases, it
can be the other one, and in some cases, only one is necessary. If I
just want to generate a midi file, the logical representation is
enough (and better), but if I just want to display a page, it is the
opposite. So if we can get a good page-oriented representation, with
maybe a stylesheet to go from one to the other (at least for not too
complicated cases), I see it as a way to avoid people to have to do it
internally for each single piece of software that needs it.

> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.

Yes, it is not the exactly the same, I agree.

Laurent

>
> Johannes
>
>
>
>
>> Laurent
>>
>> On Mon, Feb 7, 2011 at 10:53 PM, Johannes Kepper <kepper at edirom.de> wrote:
>>> Hi again,
>>>
>>> I agree that TEI's genetic encoding approach is something we should try to combine with MEI, but as Raffaele suggested, we should try to (re)use their namespace as much as possible. This thing is definitely designed for more complicated situations than most of us will encounter on a daily basis. For me, the main question is if there is a need for a smaller solution within MEI's namespace that addresses something like 80% of the situations out there. It's just like <zone> vs. SVG: Simple solution within the format vs. mighty solution by including something else. The only problem then is to find where those 80% might end, and what is needed to get there…
>>>
>>>
>>>
>>>
>>> Am 07.02.2011 um 22:43 schrieb Laurent Pugin:
>>>
>>>> Hi all,
>>>>
>>>> As Perry mentioned it, we already had conversations about adding the
>>>> opportunity to use another hierarchy depending one the goal being
>>>> pursued. The case given by Andrew a typical one where it would be much
>>>> easier with a page-oriented hierarchy. Of course, if things are well
>>>> organized, it should be possible to automatically change the
>>>> hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
>>>> reverse. With reasonably complex cases, I don't see any reason why it
>>>> could not be lossless. So one might say, if we can encode it with the
>>>> current schema and just convert it to another hierarchy internally,
>>>> why would we need another way of encoding it?
>>>>
>>>> If think that the first point is that being able to choose the most
>>>> appropriate hierarchy would make the encoding and the processing much
>>>> simpler. To some extend, it would not necessary be very different from
>>>> the score vs parts representations. And as for score and parts, it is
>>>> very ofter possible to go from one to the other, but not always, and
>>>> we could also have more complex cases where it would not be possible
>>>> to go back and forth between a page oriented and a score/parts
>>>> oriented representation.
>>>>
>>>> One interesting thing to look at is the TEI module for genetic
>>>> editions, and for our discussion in particular points 1.3 (document
>>>> vs. text) and 3 (the document level)
>>>> http://www.tei-c.org/Activities/Council/Working/tcw19.html
>>>>
>>>> It goes far beyond the simple example we are discussing here, and with
>>>> such complex cases being able to change the hierarchy without losing
>>>> anything seems very challenging. I am not sure we have to go so far,
>>>> but we should think about it because it would not necessary create
>>>> backward compatibility with the current schema. It would mainly make
>>>> it easier to use it when the goal is to encode a document with more
>>>> focus on the physical aspect of it.
>>>
>>>
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>
>>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>