openlilylib-user Mailing List for openLilyLib
Resources for LilyPond and LaTeX users writing (about) music
Status: Alpha
Brought to you by:
u-li-1973
Menu
▾
▴
openlilylib-user — General openLilyLib discussion
You can subscribe to this list here.
| 2013 |
Jan
|
Feb
|
Mar
(45) |
Apr
(38) |
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(10) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2014 |
Jan
(164) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Helge K. <Hel...@gm...> - 2016-01-02 10:54:01
|
Hi OpenLilyLib guys I just wanted to find out what OpenLilyLib can do for me. So I cloned the git repository and tried to find some useful things. The custom fonts (Bravura, Smufl) look very good. Although I didn't used too much to find the difference between these both. Next I dug into editorial-tools/partial-compilation. There is a definitions.ily. Since I don't know how to use the file I copied the content to a new .ly file and ran Lilypond on it. It failed reading the missing include file "general-tools/clip-regions/definitions.ily". I am confident that I get the same result when I include definitions.ily in my custom file as "clip-regions" is not in the repository. What is a good start to learn how to use OpenLilyLib? Best regards, Helge -- PGP Fingerprint: EDCE F8C8 B727 6CC5 7006 05C1 BD3F EADC 8922 1F61 |
|
From: Urs L. <ul...@op...> - 2014-02-06 22:30:48
|
Am 06.02.2014 22:53, schrieb NickS: > Hi Urs, > I didn't think of lualatex, I will give that a try. You have to take into account that it will only work with a fairly current lualatex. TeXLive 2013's lualatex will work, TL 2012's not. In any case this isn't an acceptable restriction, so I should try to find a solution. > Thanks very much for all your work on lilyglyphs, I'm very excited to be able to create musical documents. Glad you like it. If you're exited to use it please consider to contribute by submitting new commands ;-) Best Urs > Kind regards, > Nick > > > >> ________________________________ >> From: Urs Liska <ul...@op...> >> To: ope...@li... >> Sent: Wednesday, 5 February 2014, 11:50 >> Subject: Re: [oll-user] lilyglyphs and hyperref >> >> >> Hi NickS, >> >> thanks for the report. >> For now I don't have any idea what the reason may be or how to fix it, >> but I have added it to the issue tracker: >> https://github.com/openlilylib/lilyglyphs/issues/87 >> >> Note that using lualatex produces correct output. >> >> Best >> Urs >> >> >> Am 04.02.2014 22:01, schrieb NickS: >>> I've just started using lilyglyphs and I've noticed it interacts with the "hyperref" package to produce very large bounding boxes around section titles in the table of contents. This can be seen in the PDF generated by running xelatex on the following code: >>> >>> \documentclass{article} >>> % for lilyglyphs >>> \usepackage{fontspec} >>> \usepackage{lilyglyphs} >>> % for use without lilyglyphs >>> % \newcommand{\doublesharp}{$\sharp\sharp$} >>> % \newcommand{\flatflat}{$\flat\flat$} >>> % for hyperlinks >>> \usepackage{hyperref} >>> \author{Author} >>> \title{Title} >>> \begin{document} >>> \maketitle >>> \tableofcontents >>> \section{\texorpdfstring{The B\doublesharp}{\ref{The Bdoublesharp} The B++}} >>> This is the B\doublesharp. >>> \section{\texorpdfstring{The C\flatflat}{\ref{The Cdoubleflat} The C--}} >>> This is the C\flatflat. >>> \end{document} >>> >>> By comparison, if you comment out the two "usepackage" lines (for fontspec and lilyglyphs) and uncomment the two "newcommand" lines (for doublesharp and flatflat), the resulting PDF has normal bounding boxes (but of course not proper accidentals). >>> >>> In any case the PDF bookmark names don't like any accidentals (hence I use the "++" and "--" in the 2nd parameter of \texorpdfstring ), but it would be great if the lilyglyph symbols could be displayed in the table of contents without the very tall bounding boxes. >> >> >> ------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk >> _______________________________________________ >> openlilylib-user mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openlilylib-user >> >> >> |
|
From: NickS <nic...@ya...> - 2014-02-06 21:56:22
|
Hi Urs, I didn't think of lualatex, I will give that a try. Thanks very much for all your work on lilyglyphs, I'm very excited to be able to create musical documents. Kind regards, Nick >________________________________ > From: Urs Liska <ul...@op...> >To: ope...@li... >Sent: Wednesday, 5 February 2014, 11:50 >Subject: Re: [oll-user] lilyglyphs and hyperref > > >Hi NickS, > >thanks for the report. >For now I don't have any idea what the reason may be or how to fix it, >but I have added it to the issue tracker: >https://github.com/openlilylib/lilyglyphs/issues/87 > >Note that using lualatex produces correct output. > >Best >Urs > > >Am 04.02.2014 22:01, schrieb NickS: >> I've just started using lilyglyphs and I've noticed it interacts with the "hyperref" package to produce very large bounding boxes around section titles in the table of contents. This can be seen in the PDF generated by running xelatex on the following code: >> >> \documentclass{article} >> % for lilyglyphs >> \usepackage{fontspec} >> \usepackage{lilyglyphs} >> % for use without lilyglyphs >> % \newcommand{\doublesharp}{$\sharp\sharp$} >> % \newcommand{\flatflat}{$\flat\flat$} >> % for hyperlinks >> \usepackage{hyperref} >> \author{Author} >> \title{Title} >> \begin{document} >> \maketitle >> \tableofcontents >> \section{\texorpdfstring{The B\doublesharp}{\ref{The Bdoublesharp} The B++}} >> This is the B\doublesharp. >> \section{\texorpdfstring{The C\flatflat}{\ref{The Cdoubleflat} The C--}} >> This is the C\flatflat. >> \end{document} >> >> By comparison, if you comment out the two "usepackage" lines (for fontspec and lilyglyphs) and uncomment the two "newcommand" lines (for doublesharp and flatflat), the resulting PDF has normal bounding boxes (but of course not proper accidentals). >> >> In any case the PDF bookmark names don't like any accidentals (hence I use the "++" and "--" in the 2nd parameter of \texorpdfstring ), but it would be great if the lilyglyph symbols could be displayed in the table of contents without the very tall bounding boxes. > > >------------------------------------------------------------------------------ >Managing the Performance of Cloud-Based Applications >Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >Read the Whitepaper. >http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk >_______________________________________________ >openlilylib-user mailing list >ope...@li... >https://lists.sourceforge.net/lists/listinfo/openlilylib-user > > > -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Urs L. <ul...@op...> - 2014-02-05 11:50:32
|
Hi NickS, thanks for the report. For now I don't have any idea what the reason may be or how to fix it, but I have added it to the issue tracker: https://github.com/openlilylib/lilyglyphs/issues/87 Note that using lualatex produces correct output. Best Urs Am 04.02.2014 22:01, schrieb NickS: > I've just started using lilyglyphs and I've noticed it interacts with the "hyperref" package to produce very large bounding boxes around section titles in the table of contents. This can be seen in the PDF generated by running xelatex on the following code: > > \documentclass{article} > % for lilyglyphs > \usepackage{fontspec} > \usepackage{lilyglyphs} > % for use without lilyglyphs > % \newcommand{\doublesharp}{$\sharp\sharp$} > % \newcommand{\flatflat}{$\flat\flat$} > % for hyperlinks > \usepackage{hyperref} > \author{Author} > \title{Title} > \begin{document} > \maketitle > \tableofcontents > \section{\texorpdfstring{The B\doublesharp}{\ref{The Bdoublesharp} The B++}} > This is the B\doublesharp. > \section{\texorpdfstring{The C\flatflat}{\ref{The Cdoubleflat} The C--}} > This is the C\flatflat. > \end{document} > > By comparison, if you comment out the two "usepackage" lines (for fontspec and lilyglyphs) and uncomment the two "newcommand" lines (for doublesharp and flatflat), the resulting PDF has normal bounding boxes (but of course not proper accidentals). > > In any case the PDF bookmark names don't like any accidentals (hence I use the "++" and "--" in the 2nd parameter of \texorpdfstring ), but it would be great if the lilyglyph symbols could be displayed in the table of contents without the very tall bounding boxes. |
|
From: NickS <nic...@ya...> - 2014-02-04 21:01:40
|
Hi,
I've just started using lilyglyphs and I've noticed it interacts with the "hyperref" package to produce very large bounding boxes around section titles in the table of contents. This can be seen in the PDF generated by running xelatex on the following code:
\documentclass{article}
% for lilyglyphs
\usepackage{fontspec}
\usepackage{lilyglyphs}
% for use without lilyglyphs
% \newcommand{\doublesharp}{$\sharp\sharp$}
% \newcommand{\flatflat}{$\flat\flat$}
% for hyperlinks
\usepackage{hyperref}
\author{Author}
\title{Title}
\begin{document}
\maketitle
\tableofcontents
\section{\texorpdfstring{The B\doublesharp}{\ref{The Bdoublesharp} The B++}}
This is the B\doublesharp.
\section{\texorpdfstring{The C\flatflat}{\ref{The Cdoubleflat} The C--}}
This is the C\flatflat.
\end{document}
By comparison, if you comment out the two "usepackage" lines (for fontspec and lilyglyphs) and uncomment the two "newcommand" lines (for doublesharp and flatflat), the resulting PDF has normal bounding boxes (but of course not proper accidentals).
In any case the PDF bookmark names don't like any accidentals (hence I use the "++" and "--" in the 2nd parameter of \texorpdfstring ), but it would be great if the lilyglyph symbols could be displayed in the table of contents without the very tall bounding boxes.
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
|
|
From: Marc S. <mar...@gm...> - 2014-01-31 23:44:45
|
Thanks!— Marc Sabatella On Fri, Jan 31, 2014 at 3:50 PM, Urs Liska <ul...@op...> wrote: > Am 31.01.2014 23:43, schrieb Marc Sabatella: >> I'd love to participate in the forum, so i tried to register, but if there is a way to get the forum software to send the activation email, or to send it in a way that gets past Gmail's automatic spam filters, I haven't found it. It apparently shows as so spammy it gets deleted before it even makes it to my Spam folder?— >> Marc Sabatella > I have activated your account. > See if that helps ... > Urs > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > openlilylib-user mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlilylib-user -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Urs L. <ul...@op...> - 2014-01-31 22:50:09
|
Am 31.01.2014 23:43, schrieb Marc Sabatella: > I'd love to participate in the forum, so i tried to register, but if there is a way to get the forum software to send the activation email, or to send it in a way that gets past Gmail's automatic spam filters, I haven't found it. It apparently shows as so spammy it gets deleted before it even makes it to my Spam folder?— > Marc Sabatella I have activated your account. See if that helps ... Urs |
|
From: Marc S. <mar...@gm...> - 2014-01-31 22:43:55
|
I'd love to participate in the forum, so i tried to register, but if there is a way to get the forum software to send the activation email, or to send it in a way that gets past Gmail's automatic spam filters, I haven't found it. It apparently shows as so spammy it gets deleted before it even makes it to my Spam folder?— Marc Sabatella On Sun, Jan 26, 2014 at 5:37 PM, Janek Warchoł <lem...@gm...> wrote: > Hi all, > It's time to start discussing the engravings that are already finished. > We're also moving our discussions a forum: > http://engravingchallenges.freeforums.org > I know that this is slightly less convenient than email - my apologies! > However, it should make our discussions better available to the general > public, and after all we *do* want to show our conclusions to the world! > So, the first discussion about Estrella challenge starts here: > http://engravingchallenges.freeforums.org/submisson-1-sibelius-7-phil-holmes-t4.html > cheers, > Janek > PS i may have very limited time tomorrow as i'm writing a paper for LAC > with Urs, and the deadline is very soon... > -------------- next part -------------- > An HTML attachment was scrubbed... > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > openlilylib-user mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlilylib-user -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Janek W. <lem...@gm...> - 2014-01-29 22:04:34
|
2014-01-29 Urs Liska <ul...@op...> > Am 29.01.2014 17:39, schrieb Marc Sabatella: > > 3) the opaque-ness of the format could be an advantage if one wants to > > protect it as proprietary > > Now _that's_ probably the reason that is most worthwile if you want to > create a file format. But while not being a Free Software fundamentalist > I'd actually "reject that out of hand". > > Just yesterday I heard that German research funders (Deutsche > Forschungsgemeinschaft) will _only_ fund research projects in the area > of digital edition (music or text) that make their results (content and > software) available as open source - simply because the risk is too high > to loose the valuable information in opaque files and non-open software. > Wow! People with brains! Tell them i love them :-) Janek -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Janek W. <lem...@gm...> - 2014-01-29 22:02:08
|
2014-01-29 Marc Sabatella <ma...@ou...> > No apology necessary! There's no shame, of course, in having a > hypothesis going in to an experiment. And don't get me wrong, either. I > might be a MuseScore fanboy in some respects, but I have no illusions > here. I am quite sure that overall, for the sort of tasks these challenges > are setting forth (taking existing music and creating a new edition of it), > LilyPond as well other similar well-implemented command-line programs (I'm > partial to abcm2ps, and I hope someone volunteers to champion it here!) are > going to do very well in comparison to most WYSIWYG programs. Not that > having a command line versus WYSIWYG interface makes an inherent difference > in how one implements one's layout algorithms, but I do think there is > likely to be correlation in philosophies and this is going to affect where > one spends one's energies in implementation. That is, the developers of a > WYSIWYG program are likely to have priorities *other* than layout, and it's > likely layout will suffer for this. So I would say I share your hypothesis > here. But perhaps not the value judgement you inadvertently associated > with it. > > In my mind there are really multiple sets of tradeoffs involved when > comparing notation programs. One is the tradeoff we are focusing on here: > between having fewer manual adjustments necessary versus having those > manual adjustments easier to perform. Also, by incorporating version > control - which I think is a good thing, because it *is* important in a > collaborative project - the challenges also touch on possible tradeoffs > between having text-based formats versus binary formats. Except of course, > if there *are* advantages to binary, nothing in these challenges is likely > to expose it. > > But there are other tradeoffs that might be relevant in other sorts of > comparisons. And the ones that interest me most come into play when using > a notation program as a compositional tool as opposed to reproducing > existing music. My hypothesis is that in the same sense that command-line > programs will tend to have the upper hand in layout-based comparisons, > WYSIWYG programs will tend to have the upper hand in > compositional-process-based comparisons. Unfortunately, the > compositional-process comparisons would, I think, be much, much, harder to > perform in even the most minimally objective sense than layout comparisons. > > Still, the next interesting question to me is, to what extent are the > layout advantages of one given program offset by the compositional-process > advantages of another? And, recognizing that layout is, in the end at > least, also potentially an important part of the compositional process, to > what extent are further improvements in layout for a given program more > important than further improvements elsewhere in the compositional process, > even for someone more focused on composition than on reproduction? > > These are the issues that MuseScore has been grappling with and that will > increase in importance going forward. So to me, it is interesting to get a > sense for how *big* the gap in layout facilities is between MuseScore and > other programs including LilyPond. Perhaps even more interesting is the > matter of identifying, if possible, the biggest bang-for-the-buck areas for > improvement. But the goal I would have in mind wouldn't be to beat > LilyPond at its own game - just to get a better sense of where MuseScore > stands with respect to the tradeoff between layout and compositional > process, to help MuseScore improve *its* own game. > what can i say? +1 for everything :-) best, Janek PS sorry for such terse answer - i'd love to discuss more, but i have no time :( -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Urs L. <ul...@op...> - 2014-01-29 16:46:11
|
Hi, sorry for picking this one out of the long context. I just don't have time to enter the discussion but couldn't resist here Am 29.01.2014 17:39, schrieb Marc Sabatella: > On 1/29/2014 9:27 AM, Urs Liska wrote: >> Am 29.01.2014 17:21, schrieb Marc Sabatella: >>> Except of course, if there*are* advantages to binary, nothing >>> in these challenges is likely to expose it. >> I can't imagine any advantage of a binary format. > > I was being charitable :-). But no, there *could* be a few advantages, > depending on one's priorities: > > 1) probably could be optimized to save/load faster That's what I always thought to be the primary reason (maybe together with saving bytes in memory), but I don't really believe that's of any real relevance. > 2) by creating a system in which the user would be effectively prevented > from editing the file by hand, the developer has more control over the > input, and can hence be more lax with error checking and the verbosity > of error messages that are generated OK, that might be true, and maybe of relevance for security-relevant stuff. So it might be a good idea to prevent a pilot from manually editing the sources for the landing sequence of a 747 ;-) But I think having access to the file content is a real benefit when dealing with _documents_. Being able to version, to process by a script, to edit online etc.... > 3) the opaque-ness of the format could be an advantage if one wants to > protect it as proprietary Now _that's_ probably the reason that is most worthwile if you want to create a file format. But while not being a Free Software fundamentalist I'd actually "reject that out of hand". Just yesterday I heard that German research funders (Deutsche Forschungsgemeinschaft) will _only_ fund research projects in the area of digital edition (music or text) that make their results (content and software) available as open source - simply because the risk is too high to loose the valuable information in opaque files and non-open software. Urs > > Of course, #1 is probably inconsequential in practice, #2 is really just > an excuse for laziness (and arguably counterproductive in the long run - > as a developer, I *like* that I can examine and edit these files), and > most in the open source world would reject #3 out of hand. > > Marc > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > openlilylib-user mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlilylib-user > |
|
From: Marc S. <ma...@ou...> - 2014-01-29 16:40:00
|
On 1/29/2014 9:27 AM, Urs Liska wrote: > Am 29.01.2014 17:21, schrieb Marc Sabatella: >> Except of course, if there*are* advantages to binary, nothing >> in these challenges is likely to expose it. > I can't imagine any advantage of a binary format. I was being charitable :-). But no, there *could* be a few advantages, depending on one's priorities: 1) probably could be optimized to save/load faster 2) by creating a system in which the user would be effectively prevented from editing the file by hand, the developer has more control over the input, and can hence be more lax with error checking and the verbosity of error messages that are generated 3) the opaque-ness of the format could be an advantage if one wants to protect it as proprietary Of course, #1 is probably inconsequential in practice, #2 is really just an excuse for laziness (and arguably counterproductive in the long run - as a developer, I *like* that I can examine and edit these files), and most in the open source world would reject #3 out of hand. Marc |
|
From: Urs L. <ul...@op...> - 2014-01-29 16:27:08
|
Am 29.01.2014 17:21, schrieb Marc Sabatella: > Except of course, if there*are* advantages to binary, nothing > in these challenges is likely to expose it. I can't imagine any advantage of a binary format. Urs |
|
From: Marc S. <ma...@ou...> - 2014-01-29 16:21:21
|
On 1/29/2014 2:20 AM, Janek Warchoł wrote: > 2014-01-29 Marc Sabatella <ma...@ou... > <mailto:ma...@ou...>> > > Most of the below is meta-discussion not really relevant to the > challenges, but still, I think, interesting to think about, as it > illustrates some of the difficulties inherent in making meaningful > comparisons. > > > Yes, this is a valuable discussion! Thanks for taking my comments in the spirit in which they were intended. I just have "one" thing to add: > You're right, i'm sorry! Obviously, i'm biased towards LilyPond > here. I'll try to be more careful. No apology necessary! There's no shame, of course, in having a hypothesis going in to an experiment. And don't get me wrong, either. I might be a MuseScore fanboy in some respects, but I have no illusions here. I am quite sure that overall, for the sort of tasks these challenges are setting forth (taking existing music and creating a new edition of it), LilyPond as well other similar well-implemented command-line programs (I'm partial to abcm2ps, and I hope someone volunteers to champion it here!) are going to do very well in comparison to most WYSIWYG programs. Not that having a command line versus WYSIWYG interface makes an inherent difference in how one implements one's layout algorithms, but I do think there is likely to be correlation in philosophies and this is going to affect where one spends one's energies in implementation. That is, the developers of a WYSIWYG program are likely to have priorities *other* than layout, and it's likely layout will suffer for this. So I would say I share your hypothesis here. But perhaps not the value judgement you inadvertently associated with it. In my mind there are really multiple sets of tradeoffs involved when comparing notation programs. One is the tradeoff we are focusing on here: between having fewer manual adjustments necessary versus having those manual adjustments easier to perform. Also, by incorporating version control - which I think is a good thing, because it *is* important in a collaborative project - the challenges also touch on possible tradeoffs between having text-based formats versus binary formats. Except of course, if there *are* advantages to binary, nothing in these challenges is likely to expose it. But there are other tradeoffs that might be relevant in other sorts of comparisons. And the ones that interest me most come into play when using a notation program as a compositional tool as opposed to reproducing existing music. My hypothesis is that in the same sense that command-line programs will tend to have the upper hand in layout-based comparisons, WYSIWYG programs will tend to have the upper hand in compositional-process-based comparisons. Unfortunately, the compositional-process comparisons would, I think, be much, much, harder to perform in even the most minimally objective sense than layout comparisons. Still, the next interesting question to me is, to what extent are the layout advantages of one given program offset by the compositional-process advantages of another? And, recognizing that layout is, in the end at least, also potentially an important part of the compositional process, to what extent are further improvements in layout for a given program more important than further improvements elsewhere in the compositional process, even for someone more focused on composition than on reproduction? These are the issues that MuseScore has been grappling with and that will increase in importance going forward. So to me, it is interesting to get a sense for how *big* the gap in layout facilities is between MuseScore and other programs including LilyPond. Perhaps even more interesting is the matter of identifying, if possible, the biggest bang-for-the-buck areas for improvement. But the goal I would have in mind wouldn't be to beat LilyPond at its own game - just to get a better sense of where MuseScore stands with respect to the tradeoff between layout and compositional process, to help MuseScore improve *its* own game. Marc -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Janek W. <lem...@gm...> - 2014-01-29 09:21:20
|
Hi, 2014-01-29 Marc Sabatella <ma...@ou...> > Most of the below is meta-discussion not really relevant to the > challenges, but still, I think, interesting to think about, as it > illustrates some of the difficulties inherent in making meaningful > comparisons. > Yes, this is a valuable discussion! > > I believe that both publishers you mention had some reasons to break > the lines the way they did it, and that these reasons could be written down > as a set of precise rules (although i'm pretty sure that such rules would > be very complicated and subtle, and *very* hard to express formally). > > > Yes, this is a pretty accurate statement. There is a set of principles > explainable to and implementable by humans but next to impossible to > parameterize usefully for a computer. So in an idealized theoretical world > with flying cars and all that, sure, manual line breaks wouldn't be needed > - the desired results could be obtained using style settings only. But in > practice, it's unavoidable in contexts where one cares about the line > breaking. > > FWIW, I would suggest that one cares about line breaking "virtually > always" in the world of lead sheets and perhaps almost as often in the > world of editions of simple Baroque or classical piano music for beginners > & intermediates, also presentations of hymns, folk song arrangements, and > other contexts. But it is admittedly much less common in the world of > complex late Romantic piano music, orchestral scores and parts, and other > contexts. So differences in the types of music one mostly deals can play a > large role in what one expects of one's notation software. > Indeed. Again, I don't really follow. In the examples I gave, it isn't anything > >> about the program that makes it necessary to perform manual adjustments >> twice - it's inherent in the nature of the types of adjustments that are >> affected. > > > I don't agree, i.e. i believe that this is not inherent in the nature of > adjustments - at least some of them. > You mentioned that you have to adjust staff distances after determining > line-breaks, and if the line-breaking changes you have to redo the > adjustments. I believe that this is a deficiency of the program, i.e. > ideal notation program would automatically adjust staff distances so that > you wouldn't have to correct them when line breaking changes. > > > But that's exactly what I mean. If the program does things such that > manual adjustments to staff distance is not necessary at all, then indeed, > N = 0 in this case, and 0 * 2 is still 0. But what I am observing is that > *if* an adjustment is necessary at all (ie, if N > 1), then it *will* > likely have to be done differently for each set of line breaks (ie, N * 2 > times). The statement to which I was objecting implied that well-designed > programs would somehow bend reality such that even in cases where manual > adjustments were necessary, the same manual adjustments would always be > applicable regardless of how many different line-breakings you needed to > support. That's not going to happen even in a world with flying cars. > *If* a manual adjustment is necessary, then it *will* likely have to be > repeated - that applies to *all* programs. > Ah, it seems that i have misunderstood you previously. Indeed, i agree. > It's a subtle point, I guess, but you have to realize that in encouraging > participation by people familiar with other programs, there is likely to be > some amount of defensive reaction when these other programs are incorrectly > characterized as having "serious deficiencies" just because they cannot > change the fact that N * 2 is, well, N *2. The deficiency might be that > they have a larger N than other programs, but not the fact that two sets of > line breaks means N *2 manual adjustments - that's true no matter how big > or small your N is. > > And while this might seem petty to have to point out, I thought one of the > whole points of this challenge is to ascertain just how big a difference > there between programs is in the N-per-page values, and to what extent > these differences might be offset by the *ease* of making the necessary > adjustments. To my mind, these are interesting unanswered questions. > *Starting* with a characterization of some programs as "seriously > deficient" kind of biases things right off the bat and is not conducive to > conducting meaningful comparisons. > You're right, i'm sorry! Obviously, i'm biased towards LilyPond here. I'll try to be more careful. So indeed, a program that requires >> fewer adjustments has the advantage. But assuming a program requires N >> adjustments, performing those adjustments for two different sets of line >> breaks means potentially N*2 adjustments. >> > > Yes. That's why i believe good notation software should have as low N > as possible (let's say, in the range of 3-5 adjustments per page). > > > I agree this is a good goal. But I also think there is an element to this > that is about as naive as hoping for style settings to parameterize all the > different rules a publisher might follow in deciding line breaks. > > For instance, in the case you just cited - the decision to add extra space > between staves to accomodate hairpins - this is also a *subjective* and in > practice virtually always *human-made* decision. It's by no means a given > that space should be added between staves to accomodate hairpins. Some > editors would prefer putting the hairpins outside the staves, or allowing > them to cross staff lines, or make other adjustments in order to preserve > the consistency of staff spacing. Of those willing to tolerate > inconsistent staff spacing, Some would readily add as much space as > necessary to fit default spacing allowances, others would strive for a > compromise in which they allow things to be more crowded than they would > otherwise in order to minimize (but not eliminate) the need for extra > space, and the latter would likely want to evaluate this on a > system-by-system basis. > > As with the determination of line breaks, it might be possible to describe > a set of "house style" rules to a human, but it would like be at least as > hard to parameterize these as it would rules regarding line breaks. > Agreed; making the program understand every subtle nuance and provide options for everything is extremely hard. However, i believe that it is perfectly doable to make the software understand vast majority of such cases (something like 95%?) - much more than now. > An editor who goes in to the job willing to accept whatever his software > suggests as long as it looks good in some vague general sense is going to > have a very different experience than one who goes in to the job expecting > to make these decisions himself based on specific criteria. The former is > going to prefer software that gets to the "vaguely / generally good" state > quickly, while the latter is going to prefer software that makes the > process of getting *exactly* what he wants the easiest. > Indeed. best, Janek -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Marc S. <ma...@ou...> - 2014-01-28 23:49:01
|
Most of the below is meta-discussion not really relevant to the challenges, but still, I think, interesting to think about, as it illustrates some of the difficulties inherent in making meaningful comparisons. So, that said, here is my reply to Janek: Janek Warchoł wrote: > I believe that both publishers you mention had some reasons to break > the lines the way they did it, and that these reasons could be written > down as a set of precise rules (although i'm pretty sure that such > rules would be very complicated and subtle, and *very* hard to express > formally). Yes, this is a pretty accurate statement. There is a set of principles explainable to and implementable by humans but next to impossible to parameterize usefully for a computer. So in an idealized theoretical world with flying cars and all that, sure, manual line breaks wouldn't be needed - the desired results could be obtained using style settings only. But in practice, it's unavoidable in contexts where one cares about the line breaking. FWIW, I would suggest that one cares about line breaking "virtually always" in the world of lead sheets and perhaps almost as often in the world of editions of simple Baroque or classical piano music for beginners & intermediates, also presentations of hymns, folk song arrangements, and other contexts. But it is admittedly much less common in the world of complex late Romantic piano music, orchestral scores and parts, and other contexts. So differences in the types of music one mostly deals can play a large role in what one expects of one's notation software. > Again, I don't really follow. In the examples I gave, it isn't anything > > about the program that makes it necessary to perform manual > adjustments > twice - it's inherent in the nature of the types of adjustments > that are > affected. > > > I don't agree, i.e. i believe that this is not inherent in the nature > of adjustments - at least some of them. > You mentioned that you have to adjust staff distances after > determining line-breaks, and if the line-breaking changes you have to > redo the adjustments. I believe that this is a deficiency of the > program, i.e. ideal notation program would automatically adjust staff > distances so that you wouldn't have to correct them when line breaking > changes. But that's exactly what I mean. If the program does things such that manual adjustments to staff distance is not necessary at all, then indeed, N = 0 in this case, and 0 * 2 is still 0. But what I am observing is that *if* an adjustment is necessary at all (ie, if N > 1), then it *will* likely have to be done differently for each set of line breaks (ie, N * 2 times). The statement to which I was objecting implied that well-designed programs would somehow bend reality such that even in cases where manual adjustments were necessary, the same manual adjustments would always be applicable regardless of how many different line-breakings you needed to support. That's not going to happen even in a world with flying cars. *If* a manual adjustment is necessary, then it *will* likely have to be repeated - that applies to *all* programs. It's a subtle point, I guess, but you have to realize that in encouraging participation by people familiar with other programs, there is likely to be some amount of defensive reaction when these other programs are incorrectly characterized as having "serious deficiencies" just because they cannot change the fact that N * 2 is, well, N *2. The deficiency might be that they have a larger N than other programs, but not the fact that two sets of line breaks means N *2 manual adjustments - that's true no matter how big or small your N is. And while this might seem petty to have to point out, I thought one of the whole points of this challenge is to ascertain just how big a difference there between programs is in the N-per-page values, and to what extent these differences might be offset by the *ease* of making the necessary adjustments. To my mind, these are interesting unanswered questions. *Starting* with a characterization of some programs as "seriously deficient" kind of biases things right off the bat and is not conducive to conducting meaningful comparisons. > So indeed, a program that requires > fewer adjustments has the advantage. But assuming a program > requires N > adjustments, performing those adjustments for two different sets > of line > breaks means potentially N*2 adjustments. > > > Yes. That's why i believe good notation software should have as low N > as possible (let's say, in the range of 3-5 adjustments per page). I agree this is a good goal. But I also think there is an element to this that is about as naive as hoping for style settings to parameterize all the different rules a publisher might follow in deciding line breaks. For instance, in the case you just cited - the decision to add extra space between staves to accomodate hairpins - this is also a *subjective* and in practice virtually always *human-made* decision. It's by no means a given that space should be added between staves to accomodate hairpins. Some editors would prefer putting the hairpins outside the staves, or allowing them to cross staff lines, or make other adjustments in order to preserve the consistency of staff spacing. Of those willing to tolerate inconsistent staff spacing, Some would readily add as much space as necessary to fit default spacing allowances, others would strive for a compromise in which they allow things to be more crowded than they would otherwise in order to minimize (but not eliminate) the need for extra space, and the latter would likely want to evaluate this on a system-by-system basis. As with the determination of line breaks, it might be possible to describe a set of "house style" rules to a human, but it would like be at least as hard to parameterize these as it would rules regarding line breaks. An editor who goes in to the job willing to accept whatever his software suggests as long as it looks good in some vague general sense is going to have a very different experience than one who goes in to the job expecting to make these decisions himself based on specific criteria. The former is going to prefer software that gets to the "vaguely / generally good" state quickly, while the latter is going to prefer software that makes the process of getting *exactly* what he wants the easiest. Marc -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Janek W. <lem...@gm...> - 2014-01-28 23:19:18
|
PS my cousin Franek, who is watching the Challenges' repositories, suggested some rearrangements in the instructions. I think i like the direction in which they are moving. You can see them (and comment) here: https://github.com/engraving-challenges/main/pull/4 (just the changes) https://github.com/mcFrax/main/tree/6f83429c44f7412540d4f27158959c5960bab3ea(how the new version would look like) best, Janek -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Janek W. <lem...@gm...> - 2014-01-28 20:32:10
|
Sorry for somewhat delayed reply - i had to focus on the paper we're preparing for LAC with Urs... 2014-01-27 Marc Sabatella <ma...@ou...> > On 1/26/2014 5:35 PM, Janek Warchoł wrote: > > I agree with you that a good engraving program should not need manual > > breaking. > > This makes no sense to me. I thought I gave a pretty clear explanation > of why manual line break decisions are inherently subjective and why > good human engravers often *need* to take responsibility for these > according to the specific requirements of the situation. I suppose in > some contexts it might be OK to just let line breaks fall where the > program defaults say they should, and of course in those case, it is > reasonable to expect that the results would look "good" in some sort of > general sense. But I don't find merely looking vaguely "good" > acceptable for my own work, nor do the publishers I have worked with > accept that. Both I and the publishers I have worked with have pretty > specific - and mutually exclusive - ideas over how we want our line > breaks to fall. > > For instance, there are two different publishers I have worked with > where one can find examples of the exact same piece of music engraved by > both of them, but they have different line breaks. [...] > I see your point: there's a lot of variation in how a piece may be broken, and there is never only one "proper" way to break it. However, i restate my opinion with the following explanation: I believe that both publishers you mention had some reasons to break the lines the way they did it, and that these reasons could be written down as a set of precise rules (although i'm pretty sure that such rules would be very complicated and subtle, and *very* hard to express formally). Assuming that these "line-breaking styles" _can_ be quantified, the ideal notation program should provide general settings that would allow to choose how the lines should be broken. I.e. in an ideal notation program you should be able to say "break these lines according to Baerenreiter house style" (i.e. use a global setting) rather than having to specify breaks manually. Of course I admit that such a feature is extremely advanced and virtually non-existent among currently existing notation programs. So, we indeed have to use manual breaking quite often. > > I was thinking about asking participants to prepare two versions of > > the engraving - one with default line breaking of their program, and > > one with the line breaking the same as in the original engraving. > > However, as Marc wrote, this would be very inconvenient, as some > > participants would have to make all adjustments in two versions (well, > > this actually demonstrates that these programs have a serious weakness). > > Again, I don't really follow. In the examples I gave, it isn't anything > about the program that makes it necessary to perform manual adjustments > twice - it's inherent in the nature of the types of adjustments that are > affected. I don't agree, i.e. i believe that this is not inherent in the nature of adjustments - at least some of them. You mentioned that you have to adjust staff distances after determining line-breaks, and if the line-breaking changes you have to redo the adjustments. I believe that this is a deficiency of the program, i.e. ideal notation program would automatically adjust staff distances so that you wouldn't have to correct them when line breaking changes. However, some tweaks indeed have to be redone if line-breaking changes. > That is to say, command line programs would be just as > affected as any WYSIWYG program (if not more so) - assuming they need > manual adjustments at all, of course. Yes, being command-line or GUI doesn't have much to do with it. > So indeed, a program that requires > fewer adjustments has the advantage. But assuming a program requires N > adjustments, performing those adjustments for two different sets of line > breaks means potentially N*2 adjustments. > Yes. That's why i believe good notation software should have as low N as possible (let's say, in the range of 3-5 adjustments per page). > Oh, and by the way: i think that "adjusting global layout settings" > > should be moved before adjusting line breaks - it wouldn't make sense > > otherwise. > > Not necessarily. In many contexts - such these challenges where we are > explicitly supposed to copy line breaks - what may make most sense is to > first decide on the desired line breaks, then choose global layout > settings that achieve the optimum balance between readability and use of > space within that constraint. And in my experience, there is usually > some give and take here. That is, one chooses the line breaks one > thinks one wants, one chooses global settings to produce optimal results > within those constraints, then one re-evaluates one's line break > decision based on whether the optimal results for those constraints are > reasonable or not. Again, this is not a software-specific observation. > It applies equally well to WYSIWYG and command-line programs as well as > hand engraving. > Ok, you're right here. Choosing staff-size, margins and line-breaks should all be in one step. I'll change the instructions. best, Janek -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Phil H. <ma...@ph...> - 2014-01-27 08:35:14
|
That seems fine to me.
--
Phil Holmes
----- Original Message -----
From: Janek Warchoł
To: Phil Holmes ; OpenLilyLib User
Sent: Monday, January 27, 2014 12:35 AM
Subject: Re: [oll-user] Finally, the revised instructions - please review!
Hi all,
2014-01-26 Phil Holmes <ma...@ph...>
----- Original Message ----- From: "Janek Warchoł" <lem...@gm...
* i have added a rule that the submissions should have the same line
breaking as the original engraving. This is because if the line breaking
is significantly different, it becomes hard to compare different
engravings. What do you think?
I'm happy with everything except this. I think line-break decisions are an aspect to how good the overall result is, and thus how good the engraving program is. Forcing line breaks could easily distort the overall output. I'd accept that one of the final tweaks might be to adjust margins, staff sizes and forced linebreaks to most closely imitate the original, but it should be a final adjustment, not an early one. Early work should never involve forced breaks.
I agree with you that a good engraving program should not need manual breaking. Indeed, how each program breaks the lines is actually a part of the comparison.
I was thinking about asking participants to prepare two versions of the engraving - one with default line breaking of their program, and one with the line breaking the same as in the original engraving. However, as Marc wrote, this would be very inconvenient, as some participants would have to make all adjustments in two versions (well, this actually demonstrates that these programs have a serious weakness).
I think that we can judge the line-breaking aspect well enough even before the engraving is beautified. I.e. if the line-breaks after note entry are not the same as line-breaks of the original, then we should compare them at this stage, draw conclusions about the software, and then force line-breaks and continue working on other aspects.
Oh, and by the way: i think that "adjusting global layout settings" should be moved before adjusting line breaks - it wouldn't make sense otherwise.
Phil, what do you think?
best,
Janek
PS of course this rule doesn't apply to the already submitted engravings of the first two challenges, as they were announced earlier and participants didn't know about it when they worked.
-------------- next part --------------
An HTML attachment was scrubbed...
|
|
From: Marc S. <ma...@ou...> - 2014-01-27 01:19:39
|
On 1/26/2014 5:35 PM, Janek Warchoł wrote: > I agree with you that a good engraving program should not need manual > breaking. This makes no sense to me. I thought I gave a pretty clear explanation of why manual line break decisions are inherently subjective and why good human engravers often *need* to take responsibility for these according to the specific requirements of the situation. I suppose in some contexts it might be OK to just let line breaks fall where the program defaults say they should, and of course in those case, it is reasonable to expect that the results would look "good" in some sort of general sense. But I don't find merely looking vaguely "good" acceptable for my own work, nor do the publishers I have worked with accept that. Both I and the publishers I have worked with have pretty specific - and mutually exclusive - ideas over how we want our line breaks to fall. For instance, there are two different publishers I have worked with where one can find examples of the exact same piece of music engraved by both of them, but they have different line breaks. This difference is not because of any accident in how their software laid things out - it's because the two publishers have conflicting house standards governing these things. Any software that happened to produce results that fit one publisher's rules would automatically fail to meet the other's. In fact, one of these publishers has different set of standards that apply to one series of books versus another series - I imagine that's actually very common in the publishing world. So regardless of what software one chooses, one *will* often need to overrule default line breaks if one is trying to meet some particular set of standards (one's own, or those of the publisher one is working for). > I was thinking about asking participants to prepare two versions of > the engraving - one with default line breaking of their program, and > one with the line breaking the same as in the original engraving. > However, as Marc wrote, this would be very inconvenient, as some > participants would have to make all adjustments in two versions (well, > this actually demonstrates that these programs have a serious weakness). Again, I don't really follow. In the examples I gave, it isn't anything about the program that makes it necessary to perform manual adjustments twice - it's inherent in the nature of the types of adjustments that are affected. That is to say, command line programs would be just as affected as any WYSIWYG program (if not more so) - assuming they need manual adjustments at all, of course. So indeed, a program that requires fewer adjustments has the advantage. But assuming a program requires N adjustments, performing those adjustments for two different sets of line breaks means potentially N*2 adjustments. > I think that we can judge the line-breaking aspect well enough even > before the engraving is beautified. I.e. if the line-breaks after note > entry are not the same as line-breaks of the original, then we should > compare them at this stage, draw conclusions about the software, and > then force line-breaks and continue working on other aspects. Yes, I agree here. > Oh, and by the way: i think that "adjusting global layout settings" > should be moved before adjusting line breaks - it wouldn't make sense > otherwise. Not necessarily. In many contexts - such these challenges where we are explicitly supposed to copy line breaks - what may make most sense is to first decide on the desired line breaks, then choose global layout settings that achieve the optimum balance between readability and use of space within that constraint. And in my experience, there is usually some give and take here. That is, one chooses the line breaks one thinks one wants, one chooses global settings to produce optimal results within those constraints, then one re-evaluates one's line break decision based on whether the optimal results for those constraints are reasonable or not. Again, this is not a software-specific observation. It applies equally well to WYSIWYG and command-line programs as well as hand engraving. Of course, for pretty much any software, once one arrives at the line breaks and global layout settings one desires, it should be perfectly simple go back to the defaults and then actually apply the changes in either order. Marc |
|
From: Janek W. <lem...@gm...> - 2014-01-27 00:36:57
|
Hi all, It's time to start discussing the engravings that are already finished. We're also moving our discussions a forum: http://engravingchallenges.freeforums.org I know that this is slightly less convenient than email - my apologies! However, it should make our discussions better available to the general public, and after all we *do* want to show our conclusions to the world! So, the first discussion about Estrella challenge starts here: http://engravingchallenges.freeforums.org/submisson-1-sibelius-7-phil-holmes-t4.html cheers, Janek PS i may have very limited time tomorrow as i'm writing a paper for LAC with Urs, and the deadline is very soon... -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Janek W. <lem...@gm...> - 2014-01-27 00:36:10
|
Hi all, 2014-01-26 Phil Holmes <ma...@ph...> > ----- Original Message ----- From: "Janek Warchoł" < > lem...@gm... > > * i have added a rule that the submissions should have the same line >> breaking as the original engraving. This is because if the line breaking >> is significantly different, it becomes hard to compare different >> engravings. What do you think? >> > > > I'm happy with everything except this. I think line-break decisions are > an aspect to how good the overall result is, and thus how good the > engraving program is. Forcing line breaks could easily distort the overall > output. I'd accept that one of the final tweaks might be to adjust margins, > staff sizes and forced linebreaks to most closely imitate the original, but > it should be a final adjustment, not an early one. Early work should never > involve forced breaks. > I agree with you that a good engraving program should not need manual breaking. Indeed, how each program breaks the lines is actually a part of the comparison. I was thinking about asking participants to prepare two versions of the engraving - one with default line breaking of their program, and one with the line breaking the same as in the original engraving. However, as Marc wrote, this would be very inconvenient, as some participants would have to make all adjustments in two versions (well, this actually demonstrates that these programs have a serious weakness). I think that we can judge the line-breaking aspect well enough even before the engraving is beautified. I.e. if the line-breaks after note entry are not the same as line-breaks of the original, then we should compare them at this stage, draw conclusions about the software, and then force line-breaks and continue working on other aspects. Oh, and by the way: i think that "adjusting global layout settings" should be moved before adjusting line breaks - it wouldn't make sense otherwise. Phil, what do you think? best, Janek PS of course this rule doesn't apply to the already submitted engravings of the first two challenges, as they were announced earlier and participants didn't know about it when they worked. -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Joshua N. <jos...@gm...> - 2014-01-26 18:28:33
|
I think the general idea (and correct me if I'm wrong) is to compare already "perfected" works of art with how other notation editors fair. This means that replicating a publication quality score is key for comparison. So, fundamentally, I would disagree with the premise that we should have a say in line breaking. This also has to do with the fact that there are about as many books about notation rules and fundamental ideas about engraving as there are people who engrave, so not one approach to engraving is superior above the others. That's why I think we should stick to the finale product and replication of the version we are copying, because ultimately this isn't a challenge on which system of engraving and rules we follow are best, but how the fundamental output a program compares to another. IC, Josh On Sun, Jan 26, 2014 at 11:14 AM, Urs Liska <ul...@op...> wrote: > > > Phil Holmes <ma...@ph...> schrieb: > >But my point is that a good engraving program should not need manual > >breaking. It should just Do The Right Thing (TM). So a valid > >comparison is of the output of the programs with no manual breaking > >applied. > > > >-- > >Phil Holmes > > > > > > ----- Original Message ----- > > From: Marc Sabatella > > To: Phil Holmes > > Cc: Janek Warchoł ; OpenLilyLib User > > Sent: Sunday, January 26, 2014 4:44 PM > >Subject: Re: [oll-user] Finally, the revised instructions - please > >review! > > > > > >Everyone's workflow is surely different. For me, getting line breaks > >the way I want them early in the process is essential, because it has > >major impact on spacing. For example, consideriing just the Estrella > >challenge, until the line breaks are in, I would not know which systems > >might need extra space between staves, and until I know this, I would > >not know which markings might need manual positioning, etc. But I can > >believe others might prefer differently. So I don't know that the > >rules have to say *when* you set the line breaks - just that when it > >comes to the final comparison, in most cases, it will make for more > >sensible comparisons if we all do it the same way. If we don't choose > >the same line breaks, then we are encountering different issues, making > >comparison less meaningful. > > — > > Marc Sabatella > > > > > > > >On Sun, Jan 26, 2014 at 3:58 AM, Phil Holmes <ma...@ph...> > >wrote: > > > > > > ----- Original Message ----- > > From: "Janek Warchoł" <lem...@gm...> > > To: "OpenLilyLib User" <ope...@li...> > > Sent: Saturday, January 25, 2014 11:16 PM > > Subject: [oll-user] Finally, the revised instructions - please review! > > > > > > > Hello, > > > > > * i have added a rule that the submissions should have the same line > >> breaking as the original engraving. This is because if the line > >breaking > > > is significantly different, it becomes hard to compare different > > > engravings. What do you think? > > > > > >I'm happy with everything except this. I think line-break decisions are > >an > >aspect to how good the overall result is, and thus how good the > >engraving > >program is. Forcing line breaks could easily distort the overall > >output. > >I'd accept that one of the final tweaks might be to adjust margins, > >staff > >sizes and forced linebreaks to most closely imitate the original, but > >it > >should be a final adjustment, not an early one. Early work should never > > > > involve forced breaks. > > > > -- > > Phil Holmes > > > > > > >------------------------------------------------------------------------------ > > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > > Learn Why More Businesses Are Choosing CenturyLink Cloud For > > Critical Workloads, Development Environments & Everything In Between. > > Get a Quote or Start a Free Trial Today. > > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > > _______________________________________________ > > openlilylib-user mailing list > > ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openlilylib-user > > > > > > > >-------------- next part -------------- > >An HTML attachment was scrubbed... > > >------------------------------------------------------------------------------ > >CenturyLink Cloud: The Leader in Enterprise Cloud Services. > >Learn Why More Businesses Are Choosing CenturyLink Cloud For > >Critical Workloads, Development Environments & Everything In Between. > >Get a Quote or Start a Free Trial Today. > > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > >_______________________________________________ > >openlilylib-user mailing list > >ope...@li... > >https://lists.sourceforge.net/lists/listinfo/openlilylib-user > > Line breaking should definitely be fixed _before_ finetuning of the score. > But I agree that default line breaking is a category to be compared. > > I think everybody should definitely have a "saved state" before manual > line breaking. > Whether he then proceeds immediately with line breaking or does other > stuff like proofreading first isn't _that_ essential. > > Urs > -- > Urs Liska > openlilylib.org > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > openlilylib-user mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlilylib-user > -------------- next part -------------- An HTML attachment was scrubbed... |
|
From: Urs L. <ul...@op...> - 2014-01-26 17:14:59
|
Phil Holmes <ma...@ph...> schrieb: >But my point is that a good engraving program should not need manual >breaking. It should just Do The Right Thing (TM). So a valid >comparison is of the output of the programs with no manual breaking >applied. > >-- >Phil Holmes > > > ----- Original Message ----- > From: Marc Sabatella > To: Phil Holmes > Cc: Janek Warchoł ; OpenLilyLib User > Sent: Sunday, January 26, 2014 4:44 PM >Subject: Re: [oll-user] Finally, the revised instructions - please >review! > > >Everyone's workflow is surely different. For me, getting line breaks >the way I want them early in the process is essential, because it has >major impact on spacing. For example, consideriing just the Estrella >challenge, until the line breaks are in, I would not know which systems >might need extra space between staves, and until I know this, I would >not know which markings might need manual positioning, etc. But I can >believe others might prefer differently. So I don't know that the >rules have to say *when* you set the line breaks - just that when it >comes to the final comparison, in most cases, it will make for more >sensible comparisons if we all do it the same way. If we don't choose >the same line breaks, then we are encountering different issues, making >comparison less meaningful. > — > Marc Sabatella > > > >On Sun, Jan 26, 2014 at 3:58 AM, Phil Holmes <ma...@ph...> >wrote: > > > ----- Original Message ----- > From: "Janek Warchoł" <lem...@gm...> > To: "OpenLilyLib User" <ope...@li...> > Sent: Saturday, January 25, 2014 11:16 PM > Subject: [oll-user] Finally, the revised instructions - please review! > > > > Hello, > > > * i have added a rule that the submissions should have the same line >> breaking as the original engraving. This is because if the line >breaking > > is significantly different, it becomes hard to compare different > > engravings. What do you think? > > >I'm happy with everything except this. I think line-break decisions are >an >aspect to how good the overall result is, and thus how good the >engraving >program is. Forcing line breaks could easily distort the overall >output. >I'd accept that one of the final tweaks might be to adjust margins, >staff >sizes and forced linebreaks to most closely imitate the original, but >it >should be a final adjustment, not an early one. Early work should never > > involve forced breaks. > > -- > Phil Holmes > > >------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > openlilylib-user mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlilylib-user > > > >-------------- next part -------------- >An HTML attachment was scrubbed... >------------------------------------------------------------------------------ >CenturyLink Cloud: The Leader in Enterprise Cloud Services. >Learn Why More Businesses Are Choosing CenturyLink Cloud For >Critical Workloads, Development Environments & Everything In Between. >Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >_______________________________________________ >openlilylib-user mailing list >ope...@li... >https://lists.sourceforge.net/lists/listinfo/openlilylib-user Line breaking should definitely be fixed _before_ finetuning of the score. But I agree that default line breaking is a category to be compared. I think everybody should definitely have a "saved state" before manual line breaking. Whether he then proceeds immediately with line breaking or does other stuff like proofreading first isn't _that_ essential. Urs -- Urs Liska openlilylib.org |
|
From: Phil H. <ma...@ph...> - 2014-01-26 16:53:55
|
But my point is that a good engraving program should not need manual breaking. It should just Do The Right Thing (TM). So a valid comparison is of the output of the programs with no manual breaking applied.
--
Phil Holmes
----- Original Message -----
From: Marc Sabatella
To: Phil Holmes
Cc: Janek Warchoł ; OpenLilyLib User
Sent: Sunday, January 26, 2014 4:44 PM
Subject: Re: [oll-user] Finally, the revised instructions - please review!
Everyone's workflow is surely different. For me, getting line breaks the way I want them early in the process is essential, because it has major impact on spacing. For example, consideriing just the Estrella challenge, until the line breaks are in, I would not know which systems might need extra space between staves, and until I know this, I would not know which markings might need manual positioning, etc. But I can believe others might prefer differently. So I don't know that the rules have to say *when* you set the line breaks - just that when it comes to the final comparison, in most cases, it will make for more sensible comparisons if we all do it the same way. If we don't choose the same line breaks, then we are encountering different issues, making comparison less meaningful.
—
Marc Sabatella
On Sun, Jan 26, 2014 at 3:58 AM, Phil Holmes <ma...@ph...> wrote:
----- Original Message -----
From: "Janek Warchoł" <lem...@gm...>
To: "OpenLilyLib User" <ope...@li...>
Sent: Saturday, January 25, 2014 11:16 PM
Subject: [oll-user] Finally, the revised instructions - please review!
> Hello,
> * i have added a rule that the submissions should have the same line
> breaking as the original engraving. This is because if the line breaking
> is significantly different, it becomes hard to compare different
> engravings. What do you think?
I'm happy with everything except this. I think line-break decisions are an
aspect to how good the overall result is, and thus how good the engraving
program is. Forcing line breaks could easily distort the overall output.
I'd accept that one of the final tweaks might be to adjust margins, staff
sizes and forced linebreaks to most closely imitate the original, but it
should be a final adjustment, not an early one. Early work should never
involve forced breaks.
--
Phil Holmes
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
openlilylib-user mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openlilylib-user
-------------- next part --------------
An HTML attachment was scrubbed...
|
