Re: What is the problem with \relative? (Was: Do we really offer the future?)
That is indeed a clever way of manipulating the absolute mode good for
some things, but not terribly handy once you get into active keyboard
music as you would end up thinking like a drifting organ tuner.
Shane
On Mon, May 4, 2015 at 10:57 PM, Keith OHara k-ohara5...@oco.net wrote:
Federico Bruni fedelogy at gmail.com writes:
2015-04-23 9:21 GMT+02:00 Martin Tarenskeen m.tarenskeen at zonnet.nl:
I often use LilyPond to quickly enter a very simple tune or small
pianosheet needing just a simple texteditor (Vim). I use \relative all the
time. c g c e g is soo much faster and easier than c''' g'' c''' e''' g'''
g'''.
And personally I find lilypond code in \relative mode easier to read.
I agree that for complex scores with much music in variables \relative mode
can have annoying side-effects.
I agree: relative mode is much easier to enter.
What if we compare relative mode to absolute mode with repeated 's removed?
Is
\relative c''' { c g c e g }
easier than
\transpose c c''' { c g, c e g}
?
I find it easier to remember that a note is below the middle octave in
the range of an instrument, than to remember whether the previous note was
more than three scale-steps away.
We can easily define a shorter way to express the transposition by octaves
\absolute c''' { c g, c e g }
and it is not too hard to change the 460 examples in the manual that have
an implicit \relative c' {} or relative c'' {} to copy/paste-able music.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
+1 to Keith's idea.
In fact, I remember first learning about \relative and being *amazed* that
it didn't work as described.
I'm mostly transcribing/re-engraving for solo violin, and most pieces stay
within a small 2-octave range. The \relative c'''{ ...} syntax was exactly
what I wanted.
Steve
On Mon, May 4, 2015 at 7:57 PM, Keith OHara k-ohara5...@oco.net wrote:
Federico Bruni fedelogy at gmail.com writes:
2015-04-23 9:21 GMT+02:00 Martin Tarenskeen m.tarenskeen at zonnet.nl
:
I often use LilyPond to quickly enter a very simple tune or small
pianosheet needing just a simple texteditor (Vim). I use \relative all the
time. c g c e g is soo much faster and easier than c''' g'' c''' e''' g'''
g'''.
And personally I find lilypond code in \relative mode easier to read.
I agree that for complex scores with much music in variables \relative
mode
can have annoying side-effects.
I agree: relative mode is much easier to enter.
What if we compare relative mode to absolute mode with repeated 's removed?
Is
\relative c''' { c g c e g }
easier than
\transpose c c''' { c g, c e g}
?
I find it easier to remember that a note is below the middle octave in
the range of an instrument, than to remember whether the previous note was
more than three scale-steps away.
We can easily define a shorter way to express the transposition by octaves
\absolute c''' { c g, c e g }
and it is not too hard to change the 460 examples in the manual that have
an implicit \relative c' {} or relative c'' {} to copy/paste-able music.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Federico Bruni fedelogy at gmail.com writes:
2015-04-23 9:21 GMT+02:00 Martin Tarenskeen m.tarenskeen at zonnet.nl:
I often use LilyPond to quickly enter a very simple tune or small
pianosheet needing just a simple texteditor (Vim). I use \relative all the
time. c g c e g is soo much faster and easier than c''' g'' c''' e''' g'''
g'''.
And personally I find lilypond code in \relative mode easier to read.
I agree that for complex scores with much music in variables \relative mode
can have annoying side-effects.
I agree: relative mode is much easier to enter.
What if we compare relative mode to absolute mode with repeated 's removed?
Is
\relative c''' { c g c e g }
easier than
\transpose c c''' { c g, c e g}
?
I find it easier to remember that a note is below the middle octave in
the range of an instrument, than to remember whether the previous note was
more than three scale-steps away.
We can easily define a shorter way to express the transposition by octaves
\absolute c''' { c g, c e g }
and it is not too hard to change the 460 examples in the manual that have
an implicit \relative c' {} or relative c'' {} to copy/paste-able music.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hello Urs Urs Liska wrote ... Another important topic for commercial users may be the management of the source code for all PDFs (and other output). What do you mean here? And finally multiple people may have to working parallel on the same score. This is something that is already working absolutely great with LilyPond scores. Urs ... I just think on my 'huge score'. 24 pieces (movements) originally published with 'Piano Direction' istead of a score, I put the 17 parts (including the 'piano direction' and 'piano solo' together to a score. Per instrument each piece a single soucre file, one compilable LY per each combination (piece and instrument, as well as 'score of a single piece') for the 'editing workflow', and one compilable LY per each instrument part, transposed alternative instrument part and score (all 24 pieces) for the 'publishing workflow', some common includes (e.g. Title of the pieces) did result in more than 900 LY files. I can imagine, if ten persons are working parallel to make such an edition avalible in a short time, it's not a good idea to just save the file on a comon shared folder, with the danger to overwrite a file a colleague had modified and saved just a short time before. Well, I admit, in CAD usage the reuse of existing objects is much more complex. Urs Liska wrote Compared to the CAD software, Lilypond is missing (around it's kernel): - a graphical user interface (GUI) to enter/edit the source (with a simplified graphical representation of the music notes) I'm not clear what you mean here, but in any case this too is an issue for the IDE. Frescobaldi provides the Quick Insert panel. You can select multiple notes in the input file or the music view and then apply e.g. staccato to all notes at once. On my way-too-long wish/todo list is an object inspector/editor for Frescobaldi, which should basically be rather straightforward to implement. This panel would be aware of the grob the cursor is currently in (or the grob that has been selected in the Music View) and then show all available properties that can be tweaked for that element (actually Frescobaldi already knows about these properties which it uses for autocompletion). Then there should be convenient ways to edit values in that dialog. - automatic source code update to new versions (from open file to file loaded into the RAM of the editor) Is this really important? I'd be scared when my editor does that automatically. - point-and-click positions have idenpendent IDs, which are stable during editing the source (e.g. if you edit the LY files and insert a line) Frescobaldi does that. ... My observation on CAD usage is, approx. 3 % of the users are going to use features which are similar to programmng. The remaining 97 % use the GUI only and avoid using such features, they have to think as a programmer. I hope, for music notation users this ratio is better, but I don't believe it'll reach 20 %. So, a good GUI editor for LY files could increase the acceptance of the users a lot. And it's an important question for such a GUI, how versions updates will be handled - but this also depends on your file managment (will you save the history in the editing process?) What's to expect if you restart editing a 20 years old publication? Can only the guru process all required updated, or is the work of the guru limited to fix the remaining problems (by using an utf8 text file editor) only? IMHO, the publishing companies would prefer a complete suite of lilypond (the kernel), an editing GUI (for user acceptance) and file management (recommended at least for cooperation of multiple users) ArnoldTheresius -- View this message in context: http://lilypond.1069038.n5.nabble.com/Do-we-really-offer-the-future-tp174675p175458.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Am 27.04.2015 um 10:35 schrieb ArnoldTheresius: Hello Urs Urs Liska wrote ... Another important topic for commercial users may be the management of the source code for all PDFs (and other output). What do you mean here? And finally multiple people may have to working parallel on the same score. This is something that is already working absolutely great with LilyPond scores. Urs ... I just think on my 'huge score'. 24 pieces (movements) originally published with 'Piano Direction' istead of a score, I put the 17 parts (including the 'piano direction' and 'piano solo' together to a score. Per instrument each piece a single soucre file, one compilable LY per each combination (piece and instrument, as well as 'score of a single piece') for the 'editing workflow', and one compilable LY per each instrument part, transposed alternative instrument part and score (all 24 pieces) for the 'publishing workflow', some common includes (e.g. Title of the pieces) did result in more than 900 LY files. I can imagine, if ten persons are working parallel to make such an edition avalible in a short time, it's not a good idea to just save the file on a comon shared folder, with the danger to overwrite a file a colleague had modified and saved just a short time before. This is true. So I would *never* suggest working on a substantial project on a shared drive. But your situation is already *fr* betten than if you'd have binary/graphical documents. If you are going to collaborate you should definitely use a version control system such as Git (or any other). And then you can benefit to 100% from the text based file format, and this is where my comment about working absolutely great is targeting at. Maybe you didn't see http://lilypondblog.org/category/productions/das-trunkne-lied/ and particularly http://lilypondblog.org/2014/10/segmented-workflows/, where I describe exactly such a project. I have just asked my terminal to count the .ly/.ily files in the project directory, and the answer was 2917. We have used the collaborative approach with huge success so far. Well, I admit, in CAD usage the reuse of existing objects is much more complex. Urs Liska wrote Compared to the CAD software, Lilypond is missing (around it's kernel): - a graphical user interface (GUI) to enter/edit the source (with a simplified graphical representation of the music notes) I'm not clear what you mean here, but in any case this too is an issue for the IDE. Frescobaldi provides the Quick Insert panel. You can select multiple notes in the input file or the music view and then apply e.g. staccato to all notes at once. On my way-too-long wish/todo list is an object inspector/editor for Frescobaldi, which should basically be rather straightforward to implement. This panel would be aware of the grob the cursor is currently in (or the grob that has been selected in the Music View) and then show all available properties that can be tweaked for that element (actually Frescobaldi already knows about these properties which it uses for autocompletion). Then there should be convenient ways to edit values in that dialog. - automatic source code update to new versions (from open file to file loaded into the RAM of the editor) Is this really important? I'd be scared when my editor does that automatically. - point-and-click positions have idenpendent IDs, which are stable during editing the source (e.g. if you edit the LY files and insert a line) Frescobaldi does that. ... My observation on CAD usage is, approx. 3 % of the users are going to use features which are similar to programmng. The remaining 97 % use the GUI only and avoid using such features, they have to think as a programmer. I hope, for music notation users this ratio is better, but I don't believe it'll reach 20 %. So, a good GUI editor for LY files could increase the acceptance of the users a lot. And it's an important question for such a GUI, how versions updates will be handled - but this also depends on your file managment (will you save the history in the editing process?) What's to expect if you restart editing a 20 years old publication? Can only the guru process all required updated, or is the work of the guru limited to fix the remaining problems (by using an utf8 text file editor) only? Well, I have the impression you should have a look at http://lilypondblog.org/tag/version-control/ ;-) IMHO, the publishing companies would prefer a complete suite of lilypond (the kernel), an editing GUI (for user acceptance) and file management (recommended at least for cooperation of multiple users) Actually that's what I have in mind: LilyPond, Frescobaldi, Git (with either GitHub or a self-installed GitLab). As it's a suite it requires to set up a few things in line, which could still be simplified by either creating a setup program that installs the necessary things and guides the user through the setup of personal things like accounts. But OTOH I'm not
Re: What is the problem with \relative? (Was: Do we really offer the future?)
2015-04-25 19:17 GMT+02:00 Martin Tarenskeen m.tarensk...@zonnet.nl:
It should be mentioned that Frescobaldi creates converts
{c'' d'' e'' f'' g''}
to old style \relative syntax like:
\relative c'' {c d e f g}
instead of the new syntax I like to use these days:
\relative {c'' d e f g}
I've added a request here:
https://github.com/wbsoft/frescobaldi/issues/682
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On Sun, 26 Apr 2015 05:52:04 + (UTC)
Keith OHara k-ohara5...@oco.net wrote:
I wish the manual did not use the implicit \relative c'' {}
(sometimes \relative c' {} ) enclosing the examples. As soon as
the input gets complicated, \relative becomes difficult to figure out.
I've always considered \relative as an operation that should be applied as
close to the actual notes as possible. This gives the least suprises, if
any.
\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | }
}
This is, indeed, asking for problems...
\new PianoStaff
\new Staff { \time 2/4\relative c'' { c4 e | g g, } | }
\new Staff { \clef bass \relative c,, { c4 c' | e c } | }
-- Johan
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On 2015-04-26 15:13, Simon Albrecht wrote: If this is so easy for frescobaldi to have this converter relative2absolute, and so usefull to have input files in absolute, why not implant (implement) a commandline option to lily that would convert the relative blocks founds to absolute? Lilypond is intended for evaluating code, not for altering it. It’s perfectly fine to leave this tool for user interface software like Frescobaldi or Denemo. The relative2absolute tool used by Frescobaldi and other useful stuff actually is available from the commandline (but not as a part of LilyPond of course) since a while back. https://pypi.python.org/pypi/python-ly Best Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Il 26/04/15 09.58, Johan Vromans ha scritto:
I've always considered \relative as an operation that should be
applied as
close to the actual notes as possible. This gives the least suprises, if
any.
\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | }
}
This is, indeed, asking for problems...
\new PianoStaff
\new Staff { \time 2/4\relative c'' { c4 e | g g, } | }
\new Staff { \clef bass \relative c,, { c4 c' | e c } | }
Did you invert your examples?
I think the comment This is, indeed, asking for problems... was
related to the example above (the first one), meaning this first example
is asking for problems and the second one is better (however not
commented explicitly).
Joram
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On Sun, 26 Apr 2015 09:58:33 +0200, Johan Vromans wrote:
On Sun, 26 Apr 2015 05:52:04 + (UTC)
Keith OHara k-ohara5...@oco.net wrote:
I wish the manual did not use the implicit \relative c'' {}
(sometimes \relative c' {} ) enclosing the examples. As soon as
the input gets complicated, \relative becomes difficult to figure
out.
I've always considered \relative as an operation that should be
applied as
close to the actual notes as possible. This gives the least suprises,
if
any.
\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | }
}
This is, indeed, asking for problems...
I totally agree.
This kind of forgiveness from the LilyPond parser allows for
the ultimate bad practice of inextricably mixing typographical
information with musical information.
I fully understand and admit that the learning and notation
manual want to present self-contained examples (so that the
linked LilyPond code can readily compile), but I'm advocating
that readers should be made aware that it is only intended for
illustrating specific aspects of notation and that it should
not be done for any project for which maintainance is a concern.
[Some of the templates are complete counter-examples for this
aspect of best practices. The templates sections should probably
show an image of the intended output but link to zip file
containing the skeleton of a real project (possibly with a
README file).]
One should strive to separate editorial and musical information
to the utmost that LilyPond permits, not take advantage that
LilyPond allows for obfuscated code!
Best regards,
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Am 26.04.2015 um 14:37 schrieb Ali Cuota: Hello, If this is so easy for frescobaldi to have this converter relative2absolute, and so usefull to have input files in absolute, why not implant (implement) a commandline option to lily that would convert the relative blocks founds to absolute? Lilypond is intended for evaluating code, not for altering it. It’s perfectly fine to leave this tool for user interface software like Frescobaldi or Denemo. Yours, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hello,
If this is so easy for frescobaldi to have this converter
relative2absolute, and so usefull to have input files in absolute, why
not implant a commandline option to lily that would convert the
relatibe blocks founds to absolute?
Francois
2015-04-26 5:12 GMT-05:00, Gilles gil...@harfang.homelinux.org:
On Sun, 26 Apr 2015 09:58:33 +0200, Johan Vromans wrote:
On Sun, 26 Apr 2015 05:52:04 + (UTC)
Keith OHara k-ohara5...@oco.net wrote:
I wish the manual did not use the implicit \relative c'' {}
(sometimes \relative c' {} ) enclosing the examples. As soon as
the input gets complicated, \relative becomes difficult to figure
out.
I've always considered \relative as an operation that should be
applied as
close to the actual notes as possible. This gives the least suprises,
if
any.
\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | }
}
This is, indeed, asking for problems...
I totally agree.
This kind of forgiveness from the LilyPond parser allows for
the ultimate bad practice of inextricably mixing typographical
information with musical information.
I fully understand and admit that the learning and notation
manual want to present self-contained examples (so that the
linked LilyPond code can readily compile), but I'm advocating
that readers should be made aware that it is only intended for
illustrating specific aspects of notation and that it should
not be done for any project for which maintainance is a concern.
[Some of the templates are complete counter-examples for this
aspect of best practices. The templates sections should probably
show an image of the intended output but link to zip file
containing the skeleton of a real project (possibly with a
README file).]
One should strive to separate editorial and musical information
to the utmost that LilyPond permits, not take advantage that
LilyPond allows for obfuscated code!
Best regards,
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Dear Johan,
Il 26/04/15 09.58, Johan Vromans ha scritto:
I've always considered \relative as an operation that should be applied as
close to the actual notes as possible. This gives the least suprises, if
any.
\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | }
}
This is, indeed, asking for problems...
\new PianoStaff
\new Staff { \time 2/4\relative c'' { c4 e | g g, } | }
\new Staff { \clef bass \relative c,, { c4 c' | e c } | }
Did you invert your examples?
Actually \relative is applied closer to the notes in your second
example, which I think is clearer.
Indeed in my files I use \relative like in your second example and I
always advise people to do the same.
Best wishes.
Davide
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
it looks like you shortened \transpose not \relative but i like it I may
use it thanks
Stephen
octave =
#(define-music-function
(parser location octaves music)
(integer? ly:music?)
(_i Raise or lower @var{music} by a nubmer of @var{octaves}.)
(make-music 'TransposedMusic
'element (ly:music-transpose music (ly:make-pitch octaves 0 0
%{\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | } }
%where it could have
\new PianoStaff
\new Staff \octave 2 { \time 2/4 c4 e | g g, | }
\new Staff \octave 1 { \clef bass c,4 c | e c | }
%}
%%
%% as transpose
\new PianoStaff
\new Staff \transpose c c''{ \time 2/4 c4^as transpose e | g g, | }
\new Staff \transpose c c' { \clef bass c,4 c | e c | }
%% \relative extended
top = \relative c'' {\time 2/4 c4^\relative extended e | g g, | c4 e | g
g, | }
bottom = \relative c {c,4 c' | e c | c,4 c' | e c | }
\new PianoStaff
\new Staff {\top}
\new Staff {\clef bass\transpose c c'\bottom}
%% absolute vesion
top = {\time 2/4 c4^absolute vesion e | g g, | c4 e | g g, |}
bottom = {\clef bass c,4 c | e c | c,4 c | e c |}
\new PianoStaff
\new Staff {\transpose c c''\top}
\new Staff {\clef bass\transpose c c'\bottom}
%% \relative doesn't realy work for relative
top = \octave 2 {\time 2/4 c4^doesn't realy work for octave as relative e
| g g, | c4 e | g g, | }
bottom = \octave 1 {c,4 c' | e c | c,4 c' | e c | }
\new PianoStaff
\new Staff {\top}
\new Staff {\clef bass \bottom}
% \relative -- for \transpose it does in \relative and
absolute
top = \relative c {\time 2/4 c4^\relative -- for transpose it works e | g
g, | c4 e | g g, |}
bottom = \relative c {c,4 c' | e c | c,4 c' | e c | }
\new PianoStaff
\new Staff {\octave 2 \top}
\new Staff {\clef bass\octave 1 \bottom}
%% absolute as \transpose
top = {\time 2/4 c4^absolute version - works e | g g, | c4 e | g g, |}
bottom = {\clef bass c,4 c | e c | c,4 c | e c |}
\new PianoStaff
\new Staff {\octave 2 \top}
\new Staff {\clef bass \octave 1 \bottom}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi, I didn't want to enter the absolute/relative discussion, but now I have to add one advantage when entering notes in the relative mode: In case of a wrong , or ' (or missing) all following notes are in the wrong octave and I am more likely to spot the error. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On Sat, 25 Apr 2015, Ali Cuota wrote:
Hello,
solution is in the editors functionalities. If, let say Frescobaldi,
would offer a preprocessor to translate a block from relative to
absolute, this would be done. Relative is easy to write, absolute easy
to read, so why choose? Both is better...
Frescobaldi already offers a tool to convert relative to absolute, and absolute
to relative :-)
It should be mentioned that Frescobaldi creates converts
{c'' d'' e'' f'' g''}
to old style \relative syntax like:
\relative c'' {c d e f g}
instead of the new syntax I like to use these days:
\relative {c'' d e f g}
For relative to absolute conversion Frescobaldi can handle both.
--
MT
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Ali,
Frescobaldi does, in fact, offer the capability of changing LilyPond input code
between absolute and relative in EITHER direction.
-David
- Original Message -
From: Ali Cuota alicuota...@gmail.com
To: Simon Albrecht simon.albre...@mail.de
Cc: lilypond-user@gnu.org
Sent: Saturday, April 25, 2015 4:12:20 PM
Subject: Re: What is the problem with \relative? (Was: Do we really offer
the future?)
Hello,
I am only a user and very thankfull, both for ly and for relative. I
would have had really thought much longer about ly if relative had not
be available. Now, I understand the pro of absolute, and I think the
solution is in the editors functionalities. If, let say Frescobaldi,
would offer a preprocessor to translate a block from relative to
absolute, this would be done. Relative is easy to write, absolute easy
to read, so why choose? Both is better...
Cheers,
Francois
2015-04-25 5:34 GMT-05:00, Simon Albrecht simon.albre...@mail.de:
Am 25.04.2015 um 00:38 schrieb Thomas Morley:
Hi all,
I'm a little late to the party...
One very annoying thing about \relative is when you want to use
music-functions catching some music doing something with it.
Here the less complex function I could think of, returning different
results for absolute and relative.
(It's only a show-case, the functionality could be achieved easily
with other predefined commands, but I hope you'll get the point.)
repeat-note =
#(define-music-function (parser location music)(ly:music?)
(make-sequential-music (list music (ly:music-deep-copy music
\absolute { c'1 \repeat-note c'' }
\relative c' { c \repeat-note c'1 }
Well, either we require doing
\version 2.19.17
repeat-abs-note =
#(define-music-function (parser location music)(ly:music?)
(let ((music #{ \absolute $music #}))
(make-sequential-music (list music (ly:music-deep-copy music)
\absolute { c'1 \repeat-abs-note c'' }
\relative c' { c \repeat-abs-note c''1 }
or we consider this a bug in (or enhancement request to)
(ly:music-deep-copy), towards which I’m inclined.
Yours, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Thanks, just found it. I will consider it for my future works. Francois 2015-04-25 13:08 GMT-05:00, Noeck noeck.marb...@gmx.de: Hi, I didn't want to enter the absolute/relative discussion, but now I have to add one advantage when entering notes in the relative mode: In case of a wrong , or ' (or missing) all following notes are in the wrong octave and I am more likely to spot the error. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Martin Tarenskeen m.tarenskeen at zonnet.nl writes:
I often use LilyPond to quickly enter a very simple tune or
small pianosheet needing just a simple texteditor (Vim). I use \relative
all the time. c g c e g is soo much faster and easier than c''' g''
c''' e''' g''' g'''.
If there were a version of \transpose c c'' that was a short as \relative,
\relative c'' { c g c e g }
\octave 2 { c g, c e g }
then the \relative method is not any shorter.
The second line lets me see that the Gs are in different octaves.
And personally I find lilypond code in \relative mode easier to read.
I agree that for complex scores with much music in variables \relative
mode can have annoying side-effects.
I wish the manual did not use the implicit \relative c'' {}
(sometimes \relative c' {} ) enclosing the examples. As soon as
the input gets complicated, \relative becomes difficult to figure out.
Learning Manual 2.2.3 has
\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | } }
where it could have
\new PianoStaff
\new Staff \octave 2 { \time 2/4 c4 e | g g, | }
\new Staff \octave 1 { \clef bass c,4 c | e c | }
if there was a function
octave =
#(define-music-function
(parser location octaves music)
(integer? ly:music?)
(_i Raise or lower @var{music} by a nubmer of @var{octaves}.)
(make-music 'TransposedMusic
'element (ly:music-transpose music (ly:make-pitch octaves 0 0
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Am 25.04.2015 um 00:38 schrieb Thomas Morley:
Hi all,
I'm a little late to the party...
One very annoying thing about \relative is when you want to use
music-functions catching some music doing something with it.
Here the less complex function I could think of, returning different
results for absolute and relative.
(It's only a show-case, the functionality could be achieved easily
with other predefined commands, but I hope you'll get the point.)
repeat-note =
#(define-music-function (parser location music)(ly:music?)
(make-sequential-music (list music (ly:music-deep-copy music
\absolute { c'1 \repeat-note c'' }
\relative c' { c \repeat-note c'1 }
Well, either we require doing
\version 2.19.17
repeat-abs-note =
#(define-music-function (parser location music)(ly:music?)
(let ((music #{ \absolute $music #}))
(make-sequential-music (list music (ly:music-deep-copy music)
\absolute { c'1 \repeat-abs-note c'' }
\relative c' { c \repeat-abs-note c''1 }
or we consider this a bug in (or enhancement request to)
(ly:music-deep-copy), towards which I’m inclined.
Yours, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On Sat, 25 Apr 2015 00:38:02 +0200
Thomas Morley thomasmorle...@gmail.com wrote:
repeat-note =
#(define-music-function (parser location music)(ly:music?)
(make-sequential-music (list music (ly:music-deep-copy music
\absolute { c'1 \repeat-note c'' }
\relative c' { c \repeat-note c'1 }
So?
\repeat-note does macro expansion, so I'm inclined to say this is a feature.
-- Johan
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hello,
I am only a user and very thankfull, both for ly and for relative. I
would have had really thought much longer about ly if relative had not
be available. Now, I understand the pro of absolute, and I think the
solution is in the editors functionalities. If, let say Frescobaldi,
would offer a preprocessor to translate a block from relative to
absolute, this would be done. Relative is easy to write, absolute easy
to read, so why choose? Both is better...
Cheers,
Francois
2015-04-25 5:34 GMT-05:00, Simon Albrecht simon.albre...@mail.de:
Am 25.04.2015 um 00:38 schrieb Thomas Morley:
Hi all,
I'm a little late to the party...
One very annoying thing about \relative is when you want to use
music-functions catching some music doing something with it.
Here the less complex function I could think of, returning different
results for absolute and relative.
(It's only a show-case, the functionality could be achieved easily
with other predefined commands, but I hope you'll get the point.)
repeat-note =
#(define-music-function (parser location music)(ly:music?)
(make-sequential-music (list music (ly:music-deep-copy music
\absolute { c'1 \repeat-note c'' }
\relative c' { c \repeat-note c'1 }
Well, either we require doing
\version 2.19.17
repeat-abs-note =
#(define-music-function (parser location music)(ly:music?)
(let ((music #{ \absolute $music #}))
(make-sequential-music (list music (ly:music-deep-copy music)
\absolute { c'1 \repeat-abs-note c'' }
\relative c' { c \repeat-abs-note c''1 }
or we consider this a bug in (or enhancement request to)
(ly:music-deep-copy), towards which I’m inclined.
Yours, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Am 24.04.2015 um 00:58 schrieb Wols Lists: And then in English we get thoroughly confused, because an American whole note is an English semibreve or, literally, half note. And we don't use numbers either, we have semibreve, minim, crotchet, quaver, semiquaver, demisemiquaver, hemidemisemiquaver, dunno what the next one is. ‘semihemidemisemiquaver’ and ‘demisemihemidemisemiquaver’ :-) See http://lilypond.org/doc/v2.19/Documentation/music-glossary/duration-names-notes-and-rests. And those last three are a half note, half a half note, and half a half a half note! :-) You mean half a quaver, etc. At the end of the day, Vive La Difference! Bien sûr! Cheers, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Harm, One very annoying thing about \relative is when you want to use music-functions catching some music doing something with it. Here the less complex function I could think of, returning different results for absolute and relative. Yes — another good reason I avoid \relative mode. =) Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
2015-04-23 3:41 GMT+02:00 Kieren MacMillan kieren_macmil...@sympatico.ca:
Hi Gilles,
deprecate \relative, which I now avoid like the plague.
Why?
1. It doesn’t play well with reuse: both trivial reuse (i.e., cut-and-paste)
and more advanced (i.e., referenced in variables) require extra care at the
very least, and outright extra work (e.g., octave checks, transposition,
etc.) in most cases. This means that sharing bits of music either within a
file/piece or between files/pieces (or even between users) requires extra
work and is error-prone.
2. It makes what should be simple adjustments unnecessarily complicated, with
unnecessarily large impacts. Consider, as just one example, my paired
functions
split =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
{ \voiceOne $music1 }
\context Voice = 2 { \voiceTwo $music2 }
\oneVoice
#})
splitLU =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
{ \voiceTwo $music1 }
\context Voice = 2 { \voiceOne $music2 }
\oneVoice
#})
These (and their 3- and 4-voice counterparts) are workhorses in my code,
saving me endless amounts of typing constructs like
{ \voiceOne foo } \new Voice { \voiceTwo bar } \oneVoice
every time I simply want a short polyphonic section. I could hardly begin to
do efficient engraving work without them. Now consider the effect of
switching, in relative mode, from
b4 \split { a4 } { c,4 }
to
b4 \splitLU { c,4 } { a4 }
Because relative mode “leaves from” whatever pitch comes immediately before
it, the first example would output the b followed by a sixth “chord
immediately below it (i.e., with the a on top, sitting a second below the b),
whereas the second example would output the b followed by a third [!!]
“chord (i.e., with the c, on top, sitting a seventh below the b). In
absolute mode, I am free to choose either function (and each is necessary!)
at will, without worrying that the choice may mess up the outputted pitches.
This same sort of relative shifting happens when you want to switch the order
of notes as given in a chord, e.g. c g’ b outputs a different chord than c
b g’.
3. Many single edits suddenly require two (or more) edits as a result solely
of relative mode. For example, let’s say you have
\relative c’ { c d e a }
and you want to change the e to d. Now you must also add an apostrophe to the
a, to compensate for the relative octave adjustment:
\relative c’ { c d d a’ }
wasting effort and brainpower (if you even remember to do it the first time,
rather than compiling before finding the error).
These are only three of the problems. Worst of all, having it is a false
economy: it’s not actually intuitive for everyone (though it is for me, and
was right away), as a quick search of the archives will turn up many newbies
complaining about “how hard it is to remember when to use , and when to use ‘
and when to use nothing”.
Yes, it’s a little more work during initial entry of some music to add the
correct octavation to the pitches. But the majority of pitches I enter fall
between c, and b’’, so the difference (if any) is minimal. And of course
there are many patterns which require *more* octavation typing in relative
mode than absolute, so in those cases absolute mode saves keystrokes.
Hope this helps explain why I don’t use \relative any more, and tell most
newbies I know to avoid it.
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
Hi all,
I'm a little late to the party...
One very annoying thing about \relative is when you want to use
music-functions catching some music doing something with it.
Here the less complex function I could think of, returning different
results for absolute and relative.
(It's only a show-case, the functionality could be achieved easily
with other predefined commands, but I hope you'll get the point.)
repeat-note =
#(define-music-function (parser location music)(ly:music?)
(make-sequential-music (list music (ly:music-deep-copy music
\absolute { c'1 \repeat-note c'' }
\relative c' { c \repeat-note c'1 }
Btw, it _can_ be made to work properly with both input modes, needs
some additional coding, though.
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Federico, I see the first as less cluttered than the second (and another example of music can appear much more cluttered than above example). I see the second as containing more information encoded directly in the input, and requiring less to be added by the user. I don't like trying to see the music in the lilypond input. I prefer using point-and-click. As far as I know, we are still trying to position Lilypond as useable without a GUI, and hence without “point-and-click”. Hence we shouldn’t make decisions on fundamental structure, syntax, and so on based on hypothetical (or sometimes-real) GUI conveniences. Maybe, you, as a composer, want to see the input in a different way from me. I, as an engraver, want to know immediately what note I’m working with, without having to spend the time (in a non-GUI editor) backtracking and calculating the aggregate octave displacement. Luckily, I guess, there are both options. You are free to use the one you find superior (i.e., relative), and I will continue to use the one I find superior (i.e., absolute). =) Regards, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Am 23.04.2015 um 16:13 schrieb ArnoldTheresius: Federico Bruni wrote ... personally I find lilypond code in \relative mode easier to read. Perhaps, it's only a problem because the editors we use are not able to translate automatically between relative and absolute octave notation. Well, back to the original question, what may professional users expect from Lilypond, I would like to view Lilypond with the eyes of a mechanical engineer (using CAD programs) and a programmer (using compilers and IDEs): I'm using one of these huge (and expensive) 3D CAD programs, where you design your 3D parts, combine them into assemblies (multiple levels), and create drawings from resp. for the parts and assemblies. A modification in one part (or any 3D model) will be reflected in all it's usage (where ever it is referenced). Such a software is not a one level WYSIWYG software, you have different representations (and different tools for modification) when working on the 3D models or when working on drawings. Even such a CAD software is not used by every company - many still use 2D software because due to their requirments they do not need so complex tools which need much more training. With this background Lilypond was a software I was looking for: - the PDF output (MIDI output too) I did compare with the CAD drawings (may contain multiple sheet) and their drawing views. - the lowest level for variable I did compare with the 3D parts, the sequential and simultaneous music using these variables I did compare with the asseemblies. - one modification (e.g. corrected pitch) in the lowest level of definition will be reflected in all usages (single parts, additional parts for transposing instruments, partial scores, total score, midi output) Lilypond is (for me) a compiler - a command line compiler without IDE (integrated development environment) - and yes, I'm using it in the command line. Compared to the CAD software, Lilypond is missing (around it's kernel): - a graphical user interface (GUI) to enter/edit the source (with a simplified graphical representation of the music notes) Well, LilyPond is a compiler as you said. A C++ compiler doesn't have a GUI for simplified object management. LilyPond suggests to have dedicated IDEs for that. I assume Denemo has what you are asking for here (simplified graphical representation while entering). -- menues for all 'out of the box' modificators (articulation, overrides, tweaks, ...) I'm not clear what you mean here, but in any case this too is an issue for the IDE. Frescobaldi provides the Quick Insert panel. You can select multiple notes in the input file or the music view and then apply e.g. staccato to all notes at once. On my way-too-long wish/todo list is an object inspector/editor for Frescobaldi, which should basically be rather straightforward to implement. This panel would be aware of the grob the cursor is currently in (or the grob that has been selected in the Music View) and then show all available properties that can be tweaked for that element (actually Frescobaldi already knows about these properties which it uses for autocompletion). Then there should be convenient ways to edit values in that dialog. - automatic source code update to new versions (from open file to file loaded into the RAM of the editor) Is this really important? I'd be scared when my editor does that automatically. - point-and-click positions have idenpendent IDs, which are stable during editing the source (e.g. if you edit the LY files and insert a line) Frescobaldi does that. - 'where used' handlig -- report of the structure -- with point-and-click (in the PDF) a menu e.g.: location of pitch definition (inside variable a) | locations of variable a reference (inside variable b) | ... -- where used report while editing: this pitch definition is part of variable a, which is used in variables b and c, ... Seems like there could be good ideas in that. - quick GUI driven 'extra offset' editing, valid for just one output (PDF) target - without the need to guess a value, enter it (with tag) into the source, and recompile it, and probably adjust the value again. (My largest score now takes 25 minutes to compile and consumes 2.3 GB RAM - on Windows) We have started implementing something like this in Frescobaldi's SVG viewer (but had to stop because we have to wait for some underlying library to be more finished. What we had achieved is to be able to drag text items around and calculate the corresponding 'extra-offset from it and displaying it in an object inspector stub. Once we have the library available to properly update the source file we will add other features: - dragging of pitches - shaping of curves - reattaching items to other notes - etc. Of course this should play well together with the mentioned object editor, so you can see the values you are producing by dragging. And (hopefully) it should offer different approaches to
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Two small thoughts also from me:
– I think the preference one will take also depends on musical style: a
piece of renaissance vocal music uses so few leaps greater than a fourth
that the advantage of relative in typing is huge and it’s
‘error-pronity’ small. On the other extreme, a piano piece by George
Crumb would probably a showcase for where absolute mode is at its best,
if you get my point.
Am 23.04.2015 um 03:41 schrieb Kieren MacMillan:
Hi Gilles,
deprecate \relative, which I now avoid like the plague.
Why?
1. It doesn’t play well with reuse: both trivial reuse (i.e., cut-and-paste)
and more advanced (i.e., referenced in variables) require extra care at the
very least, and outright extra work (e.g., octave checks, transposition, etc.)
in most cases. This means that sharing bits of music either within a file/piece
or between files/pieces (or even between users) requires extra work and is
error-prone.
2. It makes what should be simple adjustments unnecessarily complicated, with
unnecessarily large impacts. Consider, as just one example, my paired functions
How about modifying these as
split =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
\relative c' { \voiceOne $music1 }
\context Voice = 2 \relative c' { \voiceTwo $music2 }
\oneVoice
#})
splitLU =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
\relative c' { \voiceTwo $music1 }
\context Voice = 2 \relative c' { \voiceOne $music2 }
\oneVoice
#})
This should reduce confusion here.
So, no reason for a crusade :-)
Yours, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On Thu, 2015-04-23 at 19:36 +0200, Eyolf Østrem wrote:
On 23.04.2015 (10:04), H. S. Teoh wrote:
Besides, only powers of 2 are valid for durations, which wastes all the
other numbers in between. Unfortunately I don't have a good idea on how
to write durations without using digits either.
I started on a vim script to remap the keyboard as follows:
-
| s | g | a | b |times| | | ' |16/64|32/128 | |
| Q | W | E | R | T | Y | U | I | O | P | | |
---
| c | d | e | f | r/R | 1 | 2 | 4 | 8 | | | |
| A | S | D | F | G | H | J | K | L | | | |
-
|undo | del |flat |sharp|breve| dot | , | | | | |
| Z | X | C | V | B | N | M | | | | |
---
So, the keyboard is completely remapped: the left hand enters the pitches,
in
the sequence of a piano keyboard, and the right hand 'plays' the rhythms,
which are laid out 'ergonomically' from the \breve (B) to the 32nd note (P):
64th and 128th notes re-use the O and P keys in shifted position, and
\longa and \maxima are placed on S-l and S-m.
Flats and sharps are added with 'c' and 'v', octaves are modified with
'i' (up) and 'm' (down), and cautionary accidentals are entered with '!'
and '?'. A \fermata is added with '.'
The script simplifies note entry for lilypond files. Three different
kinds of tasks are performed with single or just-a-few key presses:
- entry of a new note;
- modification of an existing note (wrt duration, accidentals, octave,
dots, cautionary accidentals, and articulation signs);
- certain special signs, such as fermata, musica ficta, \times x/y {}, etc.
The layout ensures that values that are likely to be close together
(stepwise motion and leaps of fourths; 'f' + 'sharp', 'e' + 'flat';
adjacent rhythm values, etc.) are close together also on the keyboard.
Any of the pitch keys (asdfwer, plus qgG for s, r, and R) enters a
single note name. Accidental modifications are rememebered, so one
doesn't have to change every 'f' to 'fis' in g major. Modifications of
the simple note is done subsequently. E.g., to turn
f into fisis!,\breve..
one would type the keys 'vv!mbnn' in any order.
With this scheme, note entry is faster than in any other note-entry system
I've tried (and I've tried a lot), perhaps excepting midi input. Most
notably in this context is that there is no jumping up and down to the
number row, and, yes, no redundancy wrt which numbers are used.
Unfortunatly, I never managed to finish it - vimscript is an odd beast -
but I've found that MuseScore can be configured to work more or less the
same way,
Well, if you set up that mapping for Denemo you could get LilyPond's
beautiful typesetting too :)
But if you *can* play a MIDI keyboard then there is no competition -
they cost less that $100 and give you note-name, octave and accidental
*and* feedback that the note you entered was the one you meant. All
going in as fast as you can play. You can even add a second pc-keyboard
mounted on your MIDI keyboard so that you can control rhythm and pitch
in one integrated interface.
Richard
so that's what I'm using now.
Eyolf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On 23.04.2015 (10:04), H. S. Teoh wrote:
Besides, only powers of 2 are valid for durations, which wastes all the
other numbers in between. Unfortunately I don't have a good idea on how
to write durations without using digits either.
I started on a vim script to remap the keyboard as follows:
-
| s | g | a | b |times| | | ' |16/64|32/128 | |
| Q | W | E | R | T | Y | U | I | O | P | | |
---
| c | d | e | f | r/R | 1 | 2 | 4 | 8 | | | |
| A | S | D | F | G | H | J | K | L | | | |
-
|undo | del |flat |sharp|breve| dot | , | | | | |
| Z | X | C | V | B | N | M | | | | |
---
So, the keyboard is completely remapped: the left hand enters the pitches, in
the sequence of a piano keyboard, and the right hand 'plays' the rhythms,
which are laid out 'ergonomically' from the \breve (B) to the 32nd note (P):
64th and 128th notes re-use the O and P keys in shifted position, and
\longa and \maxima are placed on S-l and S-m.
Flats and sharps are added with 'c' and 'v', octaves are modified with
'i' (up) and 'm' (down), and cautionary accidentals are entered with '!'
and '?'. A \fermata is added with '.'
The script simplifies note entry for lilypond files. Three different
kinds of tasks are performed with single or just-a-few key presses:
- entry of a new note;
- modification of an existing note (wrt duration, accidentals, octave,
dots, cautionary accidentals, and articulation signs);
- certain special signs, such as fermata, musica ficta, \times x/y {}, etc.
The layout ensures that values that are likely to be close together
(stepwise motion and leaps of fourths; 'f' + 'sharp', 'e' + 'flat';
adjacent rhythm values, etc.) are close together also on the keyboard.
Any of the pitch keys (asdfwer, plus qgG for s, r, and R) enters a
single note name. Accidental modifications are rememebered, so one
doesn't have to change every 'f' to 'fis' in g major. Modifications of
the simple note is done subsequently. E.g., to turn
f into fisis!,\breve..
one would type the keys 'vv!mbnn' in any order.
With this scheme, note entry is faster than in any other note-entry system
I've tried (and I've tried a lot), perhaps excepting midi input. Most
notably in this context is that there is no jumping up and down to the
number row, and, yes, no redundancy wrt which numbers are used.
Unfortunatly, I never managed to finish it - vimscript is an odd beast -
but I've found that MuseScore can be configured to work more or less the
same way, so that's what I'm using now.
Eyolf
--
A farmer with extremely prolific hens posted the following sign. Free
Chickens. Our Coop Runneth Over.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On Thu, Apr 23, 2015 at 03:35:59PM +0200, Federico Bruni wrote:
Hi Kieren
2015-04-23 14:40 GMT+02:00 Kieren MacMillan kieren_macmil...@sympatico.ca:
personally I find lilypond code in \relative mode easier to read.
Really? I look at
\relative c,, { c4 g' a b e f' g' a, b,, c’ }
and I can’t immediately tell which octave the last c is in. Looking
at
c,,4 g,, a,, b,, e, f g' a b,, c
it’s perfectly clear right away.
I see the first as less cluttered than the second (and another example
of music can appear much more cluttered than above example).
I don't like trying to see the music in the lilypond input. I prefer
using point-and-click.
Maybe, you, as a composer, want to see the input in a different way
from me.
[...]
I work directly with lilypond input with a text editor, and I originally
started out with absolute mode. But I quickly found it incredibly
tedious to type, because of all those repeated apostrophes and commas.
It makes me think that it was a wrong design decision in lilypond to use
' and , for octave indications and digits 1, 2, 4, 8, ... for durations.
If we had used digits for octave designations instead, absolute mode
would be much less painful to write, e.g.:
c5 d5 e5 f5 g5 f5 e5 d5 c5
instead of:
c''' d''' e''' f''' g''' f''' e''' d''' c'''
Besides, only powers of 2 are valid for durations, which wastes all the
other numbers in between. Unfortunately I don't have a good idea on how
to write durations without using digits either.
But as far as relative mode is concerned, I agree that it has its warts
(especially when temporary split voices have their current relative
octaves taken from the last note in the input file as opposed to the
last common voice, which is extremely annoying). However, it works
wonders when writing orchestral parts where you need to double at the
octave -- just a cut and paste with an adjustment / octave check at the
beginning and you're all set, whereas in absolute mode you have to
painstakingly edit every single note to change the octave after pasting.
In any case, regular octave checks are invaluable as a stop-gap measure
for the flaws of relative mode.
But overall, at least for me, I find the advantages of relative mode
outweigh its disadvantages compared to the tedium of writing in absolute
mode. So at least for now, I'm sticking with relative mode. Please don't
deprecate it!
T
--
Genius may have its limitations, but stupidity is not thus handicapped. --
Elbert Hubbard
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
- Original Message - From: Calixte Faure calixte.fa...@gmail.com To: Noeck noeck.marb...@gmx.de Cc: LilyPond Users lilypond-user@gnu.org Sent: Thursday, April 23, 2015 7:35:18 PM Subject: Re: What is the problem with \relative? (Was: Do we really offer the future?) I learned music in French (native French) and was at the beginning a little bit confused with 2 4 8 16 etc. because we say white, black, hooked, double-hooked, triple-, etc. but after all it is logical with the numbers. I understood the choice of 2 4 8 16 during an exchange semester in Germany where, as in American, you say half, quarter eighth, sixteenth… I proud being able to understand thanks Lilypond ! :) Apropos, why isn’t there an American language in Lilypond (do re mi fa sol la ti -e -a) ? American note names are the same as English note names and there is an English option. -David Cheers, Calixte. 2015-04-23 20:57 GMT+02:00 Noeck noeck.marb...@gmx.de : c5 d5 e5 f5 g5 f5 e5 d5 c5 All other things being equal, that *would* have been great. That would save typing in some cases and would follow American and other conventions. But c' etc. is just the natural way of calling the notes in Dutch, German and many northern and eastern European languages, pointing back to the Dutch origins of LilyPond. (Usually c, is written C though). So here in Germany it is an advantage when teaching LilyPond to newcomes: You write the notes just by their name: d' fis' a' d'' – as easy as that. Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
c5 d5 e5 f5 g5 f5 e5 d5 c5 All other things being equal, that *would* have been great. That would save typing in some cases and would follow American and other conventions. But c' etc. is just the natural way of calling the notes in Dutch, German and many northern and eastern European languages, pointing back to the Dutch origins of LilyPond. (Usually c, is written C though). So here in Germany it is an advantage when teaching LilyPond to newcomes: You write the notes just by their name: d' fis' a' d'' – as easy as that. Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On 23.04.2015 (19:40), Richard Shann wrote: Well, if you set up that mapping for Denemo you could get LilyPond's beautiful typesetting too :) The last time I tried, it wasn't possible in denemo, I think because the keyboard shortcuts were tied to specific octaves, or something like that. I've also tried to get it to work in frescobaldi, but also with no luck. MuseScore is the only frontend I've tried where it actually just works. Maybe I have to do another round. But believe me - I HAVE tried! Btw. I export from Musescore to xml and convert to ly, so the outcome is always Lilypond. Eyolf -- Just when you thought you were winning the rat race, along comes a faster rat!! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Joram, c' etc. is just the natural way of calling the notes in Dutch, German and many northern and eastern European languages So here in Germany it is an advantage when teaching LilyPond to newcomes: You write the notes just by their name: d' fis' a' d'' – as easy as that. Interesting. Relative mode must be even more confusing than normal in that case! Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
I learned music in French (native French) and was at the beginning a little bit confused with 2 4 8 16 etc. because we say white, black, hooked, double-hooked, triple-, etc. but after all it is logical with the numbers. I understood the choice of 2 4 8 16 during an exchange semester in Germany where, as in American, you say half, quarter eighth, sixteenth… I proud being able to understand thanks Lilypond ! :) Apropos, why isn’t there an American language in Lilypond (do re mi fa sol la ti -e -a) ? Cheers, Calixte. 2015-04-23 20:57 GMT+02:00 Noeck noeck.marb...@gmx.de: c5 d5 e5 f5 g5 f5 e5 d5 c5 All other things being equal, that *would* have been great. That would save typing in some cases and would follow American and other conventions. But c' etc. is just the natural way of calling the notes in Dutch, German and many northern and eastern European languages, pointing back to the Dutch origins of LilyPond. (Usually c, is written C though). So here in Germany it is an advantage when teaching LilyPond to newcomes: You write the notes just by their name: d' fis' a' d'' – as easy as that. Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Calixte Faure wrote: I learned music in French (native French) and was at the beginning a little bit confused with 2 4 8 16 etc. because we say white, black, hooked, double-hooked, triple-, etc. . At least you weren't trapped in hemi-demi-semi-quavers! - Pete ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi, It makes me think that it was a wrong design decision in lilypond to use ' and , for octave indications and digits 1, 2, 4, 8, ... for durations. If we had used digits for octave designations instead, absolute mode would be much less painful to write, e.g.: c5 d5 e5 f5 g5 f5 e5 d5 c5 All other things being equal, that *would* have been great. only powers of 2 are valid for durations I wonder if that’s true fundamentally, or if that’s just a parser limitation… It’s certainly not true for defining time signatures, moments, or other such things (which all take rational n/m), so I would think it should be possible to make Lily accept (e.g.) c3 as a valid duration. But as far as relative mode is concerned, I agree that it has its warts (especially when temporary split voices have their current relative octaves taken from the last note in the input file as opposed to the last common voice, which is extremely annoying). However, it works wonders when writing orchestral parts where you need to double at the octave -- just a cut and paste with an adjustment / octave check at the beginning and you're all set, whereas in absolute mode you have to painstakingly edit every single note to change the octave after pasting. Actually, I use \quoteDuring with \transpose; no cutting-and-pasting or editing of individual notes required. It works wonders! Best of all, if I change a note in the “original parts”, it automatically changes correctly in all the “mirrored parts”. (I did this with my last big orchestral Christmas carol arrangement: there were 9 wind parts that played only 2 patterns, so the time savings was significant.) Please don’t deprecate [relative mode]! I’m sure it won’t be deprecated, despite its many flaws. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Simon, – I think the preference one will take also depends on musical style: a piece of renaissance vocal music uses so few leaps greater than a fourth that the advantage of relative in typing is huge and it’s ‘error-pronity’ small. On the other extreme, a piano piece by George Crumb would probably a showcase for where absolute mode is at its best, if you get my point. Agreed! And since most of the music I write is my own — and hence closer to Crumb than Compere — absolute mode almost always wins the day. How about modifying these as split = […] There were, some time ago, enough problems with these functions interacting with relative mode and chords (cf. the archive thread between David K. and myself) that I’d rather not fix what isn’t currently broken. ;) This should reduce confusion here. So, no reason for a crusade :-) You’d think so… but it was that ridiculous problem with those functions + relative mode + chord notation that finally camel-strawed me. Look, I’m glad others like \relative mode. I just won’t use it — I’ve been burned far too often — and won’t recommend it to others. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Federico Bruni wrote ... personally I find lilypond code in \relative mode easier to read. Perhaps, it's only a problem because the editors we use are not able to translate automatically between relative and absolute octave notation. Well, back to the original question, what may professional users expect from Lilypond, I would like to view Lilypond with the eyes of a mechanical engineer (using CAD programs) and a programmer (using compilers and IDEs): I'm using one of these huge (and expensive) 3D CAD programs, where you design your 3D parts, combine them into assemblies (multiple levels), and create drawings from resp. for the parts and assemblies. A modification in one part (or any 3D model) will be reflected in all it's usage (where ever it is referenced). Such a software is not a one level WYSIWYG software, you have different representations (and different tools for modification) when working on the 3D models or when working on drawings. Even such a CAD software is not used by every company - many still use 2D software because due to their requirments they do not need so complex tools which need much more training. With this background Lilypond was a software I was looking for: - the PDF output (MIDI output too) I did compare with the CAD drawings (may contain multiple sheet) and their drawing views. - the lowest level for variable I did compare with the 3D parts, the sequential and simultaneous music using these variables I did compare with the asseemblies. - one modification (e.g. corrected pitch) in the lowest level of definition will be reflected in all usages (single parts, additional parts for transposing instruments, partial scores, total score, midi output) Lilypond is (for me) a compiler - a command line compiler without IDE (integrated development environment) - and yes, I'm using it in the command line. Compared to the CAD software, Lilypond is missing (around it's kernel): - a graphical user interface (GUI) to enter/edit the source (with a simplified graphical representation of the music notes) -- menues for all 'out of the box' modificators (articulation, overrides, tweaks, ...) - automatic source code update to new versions (from open file to file loaded into the RAM of the editor) - point-and-click positions have idenpendent IDs, which are stable during editing the source (e.g. if you edit the LY files and insert a line) - 'where used' handlig -- report of the structure -- with point-and-click (in the PDF) a menu e.g.: location of pitch definition (inside variable a) | locations of variable a reference (inside variable b) | ... -- where used report while editing: this pitch definition is part of variable a, which is used in variables b and c, ... - quick GUI driven 'extra offset' editing, valid for just one output (PDF) target - without the need to guess a value, enter it (with tag) into the source, and recompile it, and probably adjust the value again. (My largest score now takes 25 minutes to compile and consumes 2.3 GB RAM - on Windows) Another important topic for commercial users may be the management of the source code for all PDFs (and other output). And finally multiple people may have to working parallel on the same score. ArnoldTheresius -- View this message in context: http://lilypond.1069038.n5.nabble.com/Do-we-really-offer-the-future-tp174675p175158.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
2015-04-23 9:21 GMT+02:00 Martin Tarenskeen m.tarensk...@zonnet.nl: I often use LilyPond to quickly enter a very simple tune or small pianosheet needing just a simple texteditor (Vim). I use \relative all the time. c g c e g is soo much faster and easier than c''' g'' c''' e''' g''' g'''. And personally I find lilypond code in \relative mode easier to read. I agree that for complex scores with much music in variables \relative mode can have annoying side-effects. I agree: relative mode is much easier to enter. If you structure your files in a way that causes relative mode to produce side-effects, you can still enter in relative mode and then convert in absolute mode when you've finished (Frescobaldi can do it). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On Thu, 23 Apr 2015, Hwaen Ch'uqi wrote: Greetings, The reasons for one not using relative mode are clear, but it hardly justifies calling for its deprecation. As a composer of primarily piano music, it is an absolute lifesaver. And all to whom I have introduced LilyPond, primarily pianists or harpists, immediately gravitated to relative mode. Again, why deprecate it when you have the option of simply not using it? Hwaen Ch'uqi +1 I often use LilyPond to quickly enter a very simple tune or small pianosheet needing just a simple texteditor (Vim). I use \relative all the time. c g c e g is soo much faster and easier than c''' g'' c''' e''' g''' g'''. And personally I find lilypond code in \relative mode easier to read. I agree that for complex scores with much music in variables \relative mode can have annoying side-effects. -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Federico, If you structure your files in a way that causes relative mode to produce side-effects, you can still enter in relative mode and then convert in absolute mode when you've finished (Frescobaldi can do it). I find it just as easy to enter code in absolute mode, so why should I go through extra work? =) Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Martin,
personally I find lilypond code in \relative mode easier to read.
Really? I look at
\relative c,, { c4 g' a b e f' g' a, b,, c’ }
and I can’t immediately tell which octave the last c is in. Looking at
c,,4 g,, a,, b,, e, f g' a b,, c
it’s perfectly clear right away.
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Kieren
2015-04-23 14:40 GMT+02:00 Kieren MacMillan kieren_macmil...@sympatico.ca:
personally I find lilypond code in \relative mode easier to read.
Really? I look at
\relative c,, { c4 g' a b e f' g' a, b,, c’ }
and I can’t immediately tell which octave the last c is in. Looking at
c,,4 g,, a,, b,, e, f g' a b,, c
it’s perfectly clear right away.
I see the first as less cluttered than the second (and another example of
music can appear much more cluttered than above example).
I don't like trying to see the music in the lilypond input. I prefer
using point-and-click.
Maybe, you, as a composer, want to see the input in a different way from me.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On 23/04/15 20:35, Calixte Faure wrote: I learned music in French (native French) and was at the beginning a little bit confused with 2 4 8 16 etc. because we say white, black, hooked, double-hooked, triple-, etc. but after all it is logical with the numbers. I understood the choice of 2 4 8 16 during an exchange semester in Germany where, as in American, you say half, quarter eighth, sixteenth… I proud being able to understand thanks Lilypond ! :) Apropos, why isn’t there an American language in Lilypond (do re mi fa sol la ti -e -a) ? And then in English we get thoroughly confused, because an American whole note is an English semibreve or, literally, half note. And we don't use numbers either, we have semibreve, minim, crotchet, quaver, semiquaver, demisemiquaver, hemidemisemiquaver, dunno what the next one is. And those last three are a half note, half a half note, and half a half a half note! :-) At the end of the day, Vive La Difference! Cheers, Wol ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
What is the problem with \relative? (Was: Do we really offer the future?)
Yet another subject ;-) [...] Yet another reason to deprecate \relative, which I now avoid like the plague. (Unfortunately, I was suckered into using it when I started using Lilypond over a decade ago, so all my legacy code is in \relative mode. Using Frescobaldi, I’m slowly converting all my old code to absolute mode.) Why? Thanks, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hi Gilles,
deprecate \relative, which I now avoid like the plague.
Why?
1. It doesn’t play well with reuse: both trivial reuse (i.e., cut-and-paste)
and more advanced (i.e., referenced in variables) require extra care at the
very least, and outright extra work (e.g., octave checks, transposition, etc.)
in most cases. This means that sharing bits of music either within a file/piece
or between files/pieces (or even between users) requires extra work and is
error-prone.
2. It makes what should be simple adjustments unnecessarily complicated, with
unnecessarily large impacts. Consider, as just one example, my paired functions
split =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
{ \voiceOne $music1 }
\context Voice = 2 { \voiceTwo $music2 }
\oneVoice
#})
splitLU =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
{ \voiceTwo $music1 }
\context Voice = 2 { \voiceOne $music2 }
\oneVoice
#})
These (and their 3- and 4-voice counterparts) are workhorses in my code, saving
me endless amounts of typing constructs like
{ \voiceOne foo } \new Voice { \voiceTwo bar } \oneVoice
every time I simply want a short polyphonic section. I could hardly begin to do
efficient engraving work without them. Now consider the effect of switching, in
relative mode, from
b4 \split { a4 } { c,4 }
to
b4 \splitLU { c,4 } { a4 }
Because relative mode “leaves from” whatever pitch comes immediately before it,
the first example would output the b followed by a sixth “chord immediately
below it (i.e., with the a on top, sitting a second below the b), whereas the
second example would output the b followed by a third [!!] “chord (i.e., with
the c, on top, sitting a seventh below the b). In absolute mode, I am free to
choose either function (and each is necessary!) at will, without worrying that
the choice may mess up the outputted pitches.
This same sort of relative shifting happens when you want to switch the order
of notes as given in a chord, e.g. c g’ b outputs a different chord than c b
g’.
3. Many single edits suddenly require two (or more) edits as a result solely of
relative mode. For example, let’s say you have
\relative c’ { c d e a }
and you want to change the e to d. Now you must also add an apostrophe to the
a, to compensate for the relative octave adjustment:
\relative c’ { c d d a’ }
wasting effort and brainpower (if you even remember to do it the first time,
rather than compiling before finding the error).
These are only three of the problems. Worst of all, having it is a false
economy: it’s not actually intuitive for everyone (though it is for me, and was
right away), as a quick search of the archives will turn up many newbies
complaining about “how hard it is to remember when to use , and when to use ‘
and when to use nothing”.
Yes, it’s a little more work during initial entry of some music to add the
correct octavation to the pitches. But the majority of pitches I enter fall
between c, and b’’, so the difference (if any) is minimal. And of course there
are many patterns which require *more* octavation typing in relative mode than
absolute, so in those cases absolute mode saves keystrokes.
Hope this helps explain why I don’t use \relative any more, and tell most
newbies I know to avoid it.
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Greetings,
The reasons for one not using relative mode are clear, but it hardly
justifies calling for its deprecation. As a composer of primarily
piano music, it is an absolute lifesaver. And all to whom I have
introduced LilyPond, primarily pianists or harpists, immediately
gravitated to relative mode. Again, why deprecate it when you have the
option of simply not using it?
Hwaen Ch'uqi
On 4/22/15, Kieren MacMillan kieren_macmil...@sympatico.ca wrote:
Hi Gilles,
deprecate \relative, which I now avoid like the plague.
Why?
1. It doesn’t play well with reuse: both trivial reuse (i.e., cut-and-paste)
and more advanced (i.e., referenced in variables) require extra care at the
very least, and outright extra work (e.g., octave checks, transposition,
etc.) in most cases. This means that sharing bits of music either within a
file/piece or between files/pieces (or even between users) requires extra
work and is error-prone.
2. It makes what should be simple adjustments unnecessarily complicated,
with unnecessarily large impacts. Consider, as just one example, my paired
functions
split =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
{ \voiceOne $music1 }
\context Voice = 2 { \voiceTwo $music2 }
\oneVoice
#})
splitLU =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{
{ \voiceTwo $music1 }
\context Voice = 2 { \voiceOne $music2 }
\oneVoice
#})
These (and their 3- and 4-voice counterparts) are workhorses in my code,
saving me endless amounts of typing constructs like
{ \voiceOne foo } \new Voice { \voiceTwo bar } \oneVoice
every time I simply want a short polyphonic section. I could hardly begin to
do efficient engraving work without them. Now consider the effect of
switching, in relative mode, from
b4 \split { a4 } { c,4 }
to
b4 \splitLU { c,4 } { a4 }
Because relative mode “leaves from” whatever pitch comes immediately before
it, the first example would output the b followed by a sixth “chord
immediately below it (i.e., with the a on top, sitting a second below the
b), whereas the second example would output the b followed by a third [!!]
“chord (i.e., with the c, on top, sitting a seventh below the b). In
absolute mode, I am free to choose either function (and each is necessary!)
at will, without worrying that the choice may mess up the outputted pitches.
This same sort of relative shifting happens when you want to switch the
order of notes as given in a chord, e.g. c g’ b outputs a different chord
than c b g’.
3. Many single edits suddenly require two (or more) edits as a result solely
of relative mode. For example, let’s say you have
\relative c’ { c d e a }
and you want to change the e to d. Now you must also add an apostrophe to
the a, to compensate for the relative octave adjustment:
\relative c’ { c d d a’ }
wasting effort and brainpower (if you even remember to do it the first time,
rather than compiling before finding the error).
These are only three of the problems. Worst of all, having it is a false
economy: it’s not actually intuitive for everyone (though it is for me, and
was right away), as a quick search of the archives will turn up many newbies
complaining about “how hard it is to remember when to use , and when to use
‘ and when to use nothing”.
Yes, it’s a little more work during initial entry of some music to add the
correct octavation to the pitches. But the majority of pitches I enter fall
between c, and b’’, so the difference (if any) is minimal. And of course
there are many patterns which require *more* octavation typing in relative
mode than absolute, so in those cases absolute mode saves keystrokes.
Hope this helps explain why I don’t use \relative any more, and tell most
newbies I know to avoid it.
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
