I might not have too much to contribute, but I'd like to follow the SIG's work closely. I am particularly interested in which role the layout module could play for handling parts.<div><br></div><div>Raffaele</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Dec 10, 2012 at 11:28 AM, TW <span dir="ltr"><<a href="mailto:zupftom@googlemail.com" target="_blank">zupftom@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Me, too!<br>
<br>
Thomas<br>
<br>
<br>
2012/12/10 Laurent Pugin <<a href="mailto:laurent@music.mcgill.ca">laurent@music.mcgill.ca</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Johannes,<br>
><br>
> I am of course interested in participating to a SIG on layout questions. Who<br>
> else?<br>
><br>
> Laurent<br>
><br>
> On Thu, Dec 6, 2012 at 7:55 PM, Johannes Kepper <<a href="mailto:kepper@edirom.de">kepper@edirom.de</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> there are so many different approaches, models, proposals etc. that I<br>
>> completely lost my overview. It would be great to hear Craig's response<br>
>> regarding CSS for music, but the general intention of most of these things<br>
>> seems to be the wish for a clearer separation of content and rendition in<br>
>> order to allow multiple renditions from the same source content.<br>
>><br>
>> While I appreciate the discussion so far, I wonder if we couldn't break it<br>
>> down to more digestible issues. The question of units and their relationship<br>
>> seems to be such an issue. The possibilities of expressing pages in MEI<br>
>> seems to be another. Adopting a common algorithm, it seems the whole<br>
>> discussion would be easier to conquer when we divide it… At the same time,<br>
>> we need to make sure that we keep all the bits and pieces together. I would<br>
>> suggest to establish something like an MEI Layout SIG (special interest<br>
>> group), which coordinates the discussion of this. This group should also<br>
>> consider to apply for a session and maybe an additional workshop at the<br>
>> conference next year in May, as this seems to be an ideal time frame to<br>
>> prepare and discuss these issues. Hopefully, there will be a large part of<br>
>> the community available in Mainz, so we could take decisions there. Who<br>
>> would volunteer to participate in such a group, and what modus operandi<br>
>> would you suggest?<br>
>><br>
>> Johannes<br>
>><br>
>><br>
>> Am 06.12.2012 um 18:29 schrieb Laurent Pugin:<br>
>><br>
>> > Hi Craig,<br>
>> ><br>
>> > Thank for the very detailed report. I particularly like the randomly<br>
>> > placed staves of figure 7 ;-)<br>
>> ><br>
>> > There is certainly some interesting information about spacement,<br>
>> > especially vertically. This is closely related to the discussion we had<br>
>> > about units, and I agree that we can probably find a better name than<br>
>> > interline. I am not sure about the use of horizontal placement system<br>
>> > outside Score, though.<br>
>> ><br>
>> > For the general organization of the music, it is actually very similar<br>
>> > to what we have in Wolfgang (the music notation software create by Etienne<br>
>> > Darbellay, on which Aruspix is partially based on). Maybe not surprisingly<br>
>> > since they are from the same generation. I don't really see how this can<br>
>> > become a CSS for music. Could you tell us more about it?<br>
>> ><br>
>> > As I understand it, it would be fairly similar to what we would like to<br>
>> > achieve with the layout module in the sense that separating content and<br>
>> > presentation is what CSS does. A difference with the layout module is that<br>
>> > we have an additional level in the hierarchy, namely the systems. In Score<br>
>> > (as in Wolfgang), we have staves directly within a page, because this is<br>
>> > enough for representing them. This is a very economic way of representing a<br>
>> > page of music and it maybe has to do with the memory limitations they had<br>
>> > when they started these software applications. I am not sure this would be<br>
>> > optimal for MEI, and this is why I change the internal representation in<br>
>> > Aruspix.<br>
>> ><br>
>> > As I said, the layout module was proposed for two reasons, 1) because a<br>
>> > page-based representation did not seemed to be an interesting option at that<br>
>> > time, and 2) because it does offer a separation between content and<br>
>> > presentation (i.e., we can have several presentations for the same content).<br>
>> > This second argument seems to be appealing to several of us. I must confess,<br>
>> > however, that implementing it is quite of a challenge. I am a little be<br>
>> > concerned that because of this, it will become a very powerful solution that<br>
>> > will not be used beyond simple cases because of the complexity involved. It<br>
>> > works well with Renaissance music since the general score organization is<br>
>> > simple, we should be able to go beyond this proof of concept. As we already<br>
>> > discussed, maybe re-considering a page-based representation is a way to go.<br>
>> > This does not mean that the layout module cannot exists in parallel. But I<br>
>> > can see a fairly direct path from the Score representation as described to a<br>
>> > MEI page-based representation, and this can very well be useful to you<br>
>> > Craig, as it would be for OMR people and maybe others who would like to have<br>
>> > a very detail source encoding. What do you think?<br>
>> ><br>
>> > Best,<br>
>> > Laurent<br>
>> ><br>
>> > On Fri, Nov 30, 2012 at 4:40 AM, Craig Sapp <<a href="mailto:craigsapp@gmail.com">craigsapp@gmail.com</a>> wrote:<br>
>> > Hi Everyone,<br>
>> ><br>
>> > In case you were eagerly awaiting it, attached is the final version of<br>
>> > my analysis of staff placement in SCORE.<br>
>> ><br>
>> ><br>
>> > SCORE data itself has no concept of physical units (with some minor<br>
>> > caveats), so it would be a good model to observe. The physical units are<br>
>> > defined at the last minute when you are ready to print, and are not defined<br>
>> > while editing the music in the SCORE editor, which matches the idea which<br>
>> > you are headed towards.<br>
>> ><br>
>> > See page 50 of the attached PDF for example default spacings in SCORE<br>
>> > which is a good basic roadmap to how default spacing units are defined in<br>
>> > SCORE.<br>
>> ><br>
>> ><br>
>> ><br>
>> > > This interline distance (which is already used by MEI) is a musical<br>
>> > > unit which describes<br>
>> > > half the distance between two staff lines,<br>
>> ><br>
>> > I complain about how you are defining "interline". Interline is Latin<br>
>> > for "between lines", not "halfway between lines". This will cause continual<br>
>> > confusion, such as losing your spacecraft:<br>
>> > <a href="http://mars.jpl.nasa.gov/msp98/news/mco990930.html" target="_blank">http://mars.jpl.nasa.gov/msp98/news/mco990930.html</a><br>
>> > How about "@semiline", "@hemiline", or "@demiline" instead? Or maybe<br>
>> > "@halbline" :-)<br>
>> > <a href="http://www.dailywritingtips.com/semi-demi-and-hemi" target="_blank">http://www.dailywritingtips.com/semi-demi-and-hemi</a><br>
>> ><br>
>> ><br>
>> > * The nominal physical length of scoreDef/@interline.size in SCORE is<br>
>> > 3.15 points (0.04375 inches, 1.11125 mm). This is when you print out the<br>
>> > music using the default staff scaling and print size. Vertical values are<br>
>> > always represented by this step size, and the data files themselves do not<br>
>> > indicate that the final physical rendering is at 3.15 points (which is why I<br>
>> > had to measure it off of the example on page 50).<br>
>> ><br>
>> > * So in SCORE, the distance between two staff lines is 2.0 "steps". And<br>
>> > this means that the height of a staff is 8.0 steps. Every staff has an<br>
>> > independent scaling factor which only affects the vertical dimension (there<br>
>> > is no staff-level scaling for the horizontal dimension). So if a staff has<br>
>> > a 50% scaling, all of its steps would be 1/2 of the size of the nominal<br>
>> > height.<br>
>> ><br>
>> > * The default "successive staff spacing" is 18.0 steps, so there are<br>
>> > 18.0 - 8.0 = 10.0 steps from the top of one staff to the bottom of the next.<br>
>> > This default spacing is the framework over which individual staves may be<br>
>> > scaled. This framework is also how SCORE avoids using physical measurements<br>
>> > to place individual staves vertically on the page. Staves can be placed<br>
>> > anywhere vertically, but their placements are in relation to their default<br>
>> > positions. For example, a staff could be placed 15 steps above the top of<br>
>> > the staff below by adding an extra offset of 5 steps to its default position<br>
>> > (In SCOREese, set P4=5 for the top staff).<br>
>> ><br>
>> > * The staves each have their own scaling factor (called the staff's P5<br>
>> > in SCOREese). If P5 is 0.5, then the local staff's step size is now 1/2 of<br>
>> > the default step size. This scaling factor only affects the height of the<br>
>> > staves, not the length of the staves. Object placed on a staff will have<br>
>> > the staff's P5 scaling applied to their horizontal and vertical dimensions<br>
>> > (they will shrink by 50% if the staff is scaled by 50%), their vertical<br>
>> > placement will be scaled as well, but not their horizontal placement which<br>
>> > is independent of the staff scaling. Note that changing the scaling of a<br>
>> > staff does not affect its default position on the page, but if there is a<br>
>> > vertical offset from the default position, that offset will be scaled.<br>
>> ><br>
>> > * The horizontal distances in SCORE are described on a different scale<br>
>> > than the vertical distances. They are described as the fractional position<br>
>> > along the left/right sides of the default staff length. The nominal length<br>
>> > of a staff is 7.5 inches. This length is divided up into 200 units, so the<br>
>> > left side of staves are at 0.0, and the right side is at 200.0. A length of<br>
>> > 540 points (7.5 inches) divided by 200 is 2.7 points, so "200" was probably<br>
>> > used to give an approximately equivalent unit to vertical steps. It would<br>
>> > have been more elegant to set the default horizontal and vertical units to<br>
>> > be the same by using a different vertical scaling... In any case the<br>
>> > horizontal units are 6/7 of the vertical step units, so if you set a staff's<br>
>> > scaling to 6/7 (85.71428...%), the horizontal units will match the vertical<br>
>> > steps locally for that staff. Another way of thinking about the<br>
>> > relationship between the horizontal and vertical units in SCORE is that the<br>
>> > default length of staves is 171.428... steps long. So all vertical and<br>
>> > horizontal units can be related and a final scaling can be given to match to<br>
>> > the specified @interline physical distance between steps.<br>
>> ><br>
>> > * horizontal units cannot be scaled within the SCORE editor, and can<br>
>> > only be scaled at print time, such as to match the staff lengths to the<br>
>> > distance between page margins.<br>
>> ><br>
>> > For final placement on a physical page, there are three important<br>
>> > values:<br>
>> ><br>
>> > (1) The distance from the left side of the page to the left side of the<br>
>> > staff (the "left margin", although the system brackets will fall into this<br>
>> > margin, so not exactly the same as a text margin). The default left margin<br>
>> > is 0.5 inches (plus a fixed extra 0.025 in).<br>
>> ><br>
>> > (2) The distance from the bottom of the page to the bottom line of the<br>
>> > first staff. This is also not exactly a "margin" in the text sense, since<br>
>> > notes/slurs/dynamics can fall within this bottom margin. The default bottom<br>
>> > margin is 0.75 inches (plus a fixed extra 0.0625 inches).<br>
>> ><br>
>> > (3) The page scaling. This is the method to control the horizontal<br>
>> > scale which is not possible within the SCORE editor (other than trivial<br>
>> > zooming). But the page scaling will also affect the vertical scale at the<br>
>> > same time. The origin for the page scaling is the point defined by (1) and<br>
>> > (2) above. In other words the page scaling does not affect the page<br>
>> > margins, but rather only affects the scaling of the music (you have to scale<br>
>> > the music so that it falls at the correct top and right margin positions on<br>
>> > your page.<br>
>> ><br>
>> > Notice that only two margins are defined when printing from SCORE. This<br>
>> > perhaps gets to the point that Andrew was trying to make:<br>
>> ><br>
>> ><br>
>> > > The concept of "physical" unit doesn't really translate well to<br>
>> > > editions that are meant for digital consumption only.<br>
>> > > If I have a page meant for a tablet or digital music stand display,<br>
>> > > what does the "inch" unit mean? Does it mean<br>
>> > > render it as a physical inch on the screen, regardless of how many<br>
>> > > pixels it takes to represent it? Or does it<br>
>> > > mean render it using a fixed number of pixels-per-inch, regardless of<br>
>> > > how large or small it makes it from one<br>
>> > > display to another. E-ink displays challenge this concept, since they<br>
>> > > don't really have pixels, and high-resolution<br>
>> > > displays also challenge it since the number of pixels it takes to<br>
>> > > represent a single physical unit can be completely<br>
>> > > different. So we'll probably need some sort of proportional unit so<br>
>> > > that we can say that the page margin is a<br>
>> > > percentage of the rendered display rather than a fixed unit of<br>
>> > > physical measurement.<br>
>> ><br>
>> > SCORE uses a single origin when printing the music on a page (left and<br>
>> > bottom margins). And it is up to you to scale the music to correctly fit<br>
>> > within the top and right margins of your desired paper size (or screen size,<br>
>> > e-reader size, etc.). This could be done by specifying the top and right<br>
>> > margins instead of scaling, but page-level scaling and top/right margins<br>
>> > cannot be controlled independently in SCORE.<br>
>> ><br>
>> ><br>
>> > -=+Craig<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > mei-l mailing list<br>
>> > <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>> > <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > mei-l mailing list<br>
>> > <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>> > <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> mei-l mailing list<br>
>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div></div></blockquote></div><br></div>