RE: associatedVoice in 2.10.8
Thanks for the fast reply, but now in 2.10.9 the syllables sau and rus
are not applied to Voice lahlah.
-Original Message-
From: Georg Dummer [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 10:52 AM
To: 'lilypond-user'
Subject: associatedVoice in 2.10.8
Hi all,
I changed the example for the associated voices a bit (first
part of the tuplet in the alternative voice is a rest instead
of a note) to demonstrate my problem. In version 2.8.8 the
syllable ran is shifted to the next note properly. Version
2.10.8 says:
Lyric syllable does not have note. Use \lyricsto or
associatedVoice.
ran --
And applies the syllable to the rest.
Is this a bug or did the behaviour of associatedVoice changed.
Regards Georg
\relative \new Voice = lahlah {
\set Staff.autoBeaming = ##f
c4
\new Voice = alternative {
\voiceOne
\times 2/3 {
% show associations clearly.
\override NoteColumn #'force-hshift = #-3
r8 f g
}
}
{
\voiceTwo
f8.[ g16]
\oneVoice
}
a8( b) c
}
\new Lyrics \lyricsto lahlah {
Ju -- ras -- sic Park
}
\new Lyrics \lyricsto lahlah {
% Tricky: need to set associatedVoice
% one syllable too soon!
\set associatedVoice = alternative % applies to ran
Ty --
ran --
no --
\set associatedVoice = lahlah % applies to rus
sau -- rus Rex
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bad phrasing slur
Jean-marc, thank you, I've been on the road the whole week, just back.
Am 02/01/2007 um 11:23 schrieb Jean-marc LEGRAND:
Hi !
I don't quite understand your question, but maybe the answer is :
\version 2.10.0
\relative c' {
\clef treble
\key bes \major
\time 3/4
\partial 4*1 f4
bes \(( d8 c) d bes g'4 \) es2
}
I have put \( after the bes and not before.
Is that what you wanted to do ?
No, I need the phrasing slur to begin with the first note, the upbeat
f. This happens too, but the slur should not begin at the head of the
note. This happens in the following example:
\version 2.10.0
\relative
{
\clef treble
\key bes \major
\time 3/4
\partial 4*1
f4 \( bes( d8 c) d bes g'4 \) es2
}
But, I don't know why, if I include the example's last note in the
phrasing slur, like this:
\version 2.10.0
\relative
{
\clef treble
\key bes \major
\time 3/4
\partial 4*1
f4 \( bes( d8 c) d bes g'4 es2 \)
}
then the phrasing slur is as it should be, beginning at the other end
of the f-note. Any ideas?
Manuel
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Absolute Beginners - Chapter One
Am 02/01/2007 um 21:43 schrieb Brett Duncan: Just a small typo: If you need, say, an eight-note anacrusis should be If you need, say, an /eighth/-note anacrusis Of course! - Thank you. Manuel Brett -- Brett Duncan [EMAIL PROTECTED] Always do right - this will gratify some and astonish the rest. Mark Twain ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Absolute Spanish Beginners
Am 03/01/2007 um 13:20 schrieb luis jure: i'm sorry i'm leaving on holidays for a month, i would like to collaborate on the spanish translation. i've been teaching theory and harmony for so many years, that i have very strong opinions on terminological issues... :-) best, lj Hola Luis, please let us know when you are back - your help most welcome! Manuel P.S. this list is in English, if you wish to talk castellano, do write me privately (goes for everybody too) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Off-Topic: Orchestration Aid
Manuel libros at limay.de writes: Kennan has quite a few examples from Stravinsky, Ligeti, Webern, Schoenberg, Stockhausen, and others, especially when dealing with full orchestra and with percussion, but it is not mainly dedicated to contemporary techniques. Manuel Kennan is the standard work in English today. Also excellent is Alfred Blatter's book Orchestration and Instrumentation (or maybe I have the title backwards), which contains many contemporary examples and a chapter on voices. It's poorly edited in some spots, but quite comprehensive. Best, -- Marnen E. Laibow-Koser [EMAIL PROTECTED] http://www.marnen.org Composer / Engraver / Web developer ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Friday 05 January 2007 22:53, [EMAIL PROTECTED] wrote:
. . . The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
OK. Thank you for clarifying that. I understand, from your original
remarks, that (here) you have written just \tuplet in the interest of
brevity, and that the full form would be
\tupletSequence 3:2 {{c d e} {{f g} a} b c}
meaning
\tuplet 3:2 {c d e} \tuplet 3:2 {{f g} a} \tuplet 3:2 b \tuplet 3:2 c
yes, that's right.
which implies the following things:
a) tupletSequence is a Scheme function which just breaks up its
subexpressions naively, without any semantic analysis.
b) \tuplet is a real LilyPond function; it is identical to \times,
except that the notation 3:2 (meaning 2/3) would be allowed.
c) People would have to write \tupletSequence m:n { {...} {...} },
not \tuplet m:n { {...} {...} }.
yep, this is right (thanks for expressing it clearly).
d) Any semantic errors in the subexpressions would be reported by the
\tuplet function, not by the \tupletSequence Scheme function.
technically this is not correct (the \tuplet function doesn't detect semantic
errors), but in principle you're right (\tuplet and \tupletSequence actually
only create Music data structures, without performing semantic analysis;
most 'semantic errors' are detected either when these data structures are
further processed into typeset scores, or by the parser before the function
applications)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: associatedVoice in 2.10.8
Thank you for the fast answer. Now I have the problem that the syllable
sau is applied one note to late to voice lahlah.
\relative \new Voice = lahlah {
\set Staff.autoBeaming = ##f
c4
\new Voice = alternative {
\voiceOne \tiny
% show associations clearly.
\override NoteColumn #'force-hshift = #-3
f8 f
}
{
\voiceTwo
r8 d
\oneVoice
}
d4 d8 d
}
\new Lyrics \lyricsto lahlah {
Ju -- ras -- sic Park
}
\new Lyrics \lyricsto lahlah {
\set associatedVoice = alternative % applies to ran
Ty --
ran --
\set associatedVoice = lahlah % applies to sau
no -- sau -- rus Rex
}
-Original Message-
From: Han-Wen Nienhuys [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 12:30 PM
To: Georg Dummer
Cc: 'lilypond-user'
Subject: Re: associatedVoice in 2.10.8
Georg Dummer escreveu:
Hi all,
I changed the example for the associated voices a bit (first part of
the tuplet in the alternative voice is a rest instead of a note) to
demonstrate my problem. In version 2.8.8 the syllable ran
is shifted
to the next note properly. Version 2.10.8 says:
Lyric syllable does not have note. Use \lyricsto or
associatedVoice.
ran --
And applies the syllable to the rest.
http://code.google.com/p/lilypond/issues/detail?id=221
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: User Experience Engineering
Linda Seltzer wrote: Dear Friends, Having previously worked at ATT Labs, where I was a member of the User Experience Forum, I would like to make a few comments as a relative outsider seeing the Lilypond project for the first time. This is a great endeavor and the software output is beautiful. I would greatly encourage the project to focus on the user interface and the user experience if this is to catch on in a large way. Having to install separate editors (and who knows what bugs that will bring and what other mailing lists one will have to subscribe to...) or get into the system with DOS commands, and to understand what is wrong if the flags are wrong, etc. does not constitute user interface engineering. A smooth user interface employing the standard already-debugged platforms, such as Notepad and Word on Windows, with everything bug free, is more important than more and more detailed features, which can be added later. Every 10 minues spent system administrating and installing things is 10 minutes that real work doesn't get accomplished. User experience engineering is just as important as other areas of software development. Sincerely, Linda Seltzer ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user Linda, I use Windows and I stopped using GUI based notation simply because I am, I estimate, about 50 times more productive with lilypond. But this productivity did not come without the pain of learing the language and writing my templates to be re-useable. Also a good text editor that supports lilypond syntax, and separates scheme syntax, is essential for the beginner. I suggest you use the Context editor for windows from here: http://www.context.cx/ And also download the extensive lilypond hilighter I wrote for Context, it has over 500 reserved words hilighted from here: http://forum.context.cx/index.php?topic=1396.0 This is an excellent editor that will launch lilypond adobe and the lilypond manual which will become your best friend, just like the soldiers best friend is his rifle, it's all in the manual, or just ask here. To give you an idea of productivity... I have scored some 200 of my own and others arrangements to date. If I were to do this in GUI I would still be massaging the first 10 scores with my mouse, all piece-meal. With lilypond you can write batch jobs to make global changes adcross all 200 scores very easily. With GUI all your work is one-at-a-time and laborious. Good Luck, (and your choice of computer platform is irrelavant, Windows will work just fine as any). Rick -- View this message in context: http://www.nabble.com/User-Experience-Engineering-tf859298.html#a8198329 Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: User Experience Engineering
Hi, Linda (et al.): I would greatly encourage the project to focus on the user interface and the user experience if this is to catch on in a large way. I totally agree: if Lilypond is to catch on in a large way (with the less-geeky public), then the UI has to be vastly improved. However, I would much rather the team continue to improve the engine -- as they have been -- rather than focus on a market already dominated (and saturated) by other more standard apps. But of course, that's one of the great things about open source software: if someone feels so inclined, they can do something just like you're suggesting. In other words, feel free to: (a) Build a great user interface yourself; or, (b) Sponsor (i.e., hire) someone else to do it. I must also second Rick's statement I stopped using GUI based notation simply because I am, I estimate, about 50 times more productive with lilypond. For me, I would say I've seen 15-20x increase in productivity. (And for the record, I *taught* Finale to undergraduates, so it wasn't from a lack of ability on other applications...) Best regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: User Experience Engineering
Am 06/01/2007 um 22:14 schrieb Kieren MacMillan: I totally agree: if Lilypond is to catch on in a large way (with the less-geeky public), then the UI has to be vastly improved. I certainly don't feel the need of a graphic interface. I have recently seen several composers happily pushing those beautiful little buttons to input their music, with and without midi-keyboards, only to find afterwards that they needed much more time to finish their score by doing ridiculous things like erasing empty measures, for instance. And of course, we can type in our music much faster. Otherwise, I agree with Kieren. Manuel ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
My point when I started this topic was not to change the whole definition of
the \times function. In fact, I think the function works quite well as it
is. I was mostly talking about improving the interface - i.e. the words
and the syntax we use to call the functions - to make it more intuitive,
especially for a non-programmer. The \times function was an example among
other. I was proposing to change it to \tuplet x:y, simply because it is
closer to the musicians' language (tuplet), and it reflects more the result
we see and we would write manually (3:2 or 7:5, even if we have 6
sixteenth-notes for the 7:5 in contemporary music).
In fact, if we forget a few little bugs, LilyPond is already VERY powerful
and versatile. The point is not much to improve its features (even if it is
important), but to improve - even maybe rethink - its code entry. Some
symbols, most of the basics in fact, work very well (the notes names (a b
c), the durations (4., 8, 16, \breve), \stemUp, \cadenzaOn, the fantastic
*x/y function, etc.). But the syntax gets hard when getting in
kind-of-Scheme syntax for every tweak, and it changes a lot!
For example, we can write :
\override Voice.Stem #'transparent = ##t
#'(set-global-staff-size 13)
\set fontSize = #14
\override Voice.NoteHead #'stencil = (ly:make-textscript) (?) (which is a
function, why not simply a font character?)
And I am sure to make mistakes!
Just to make functions with a more constant syntax would be a great help for
us, simple users. Like making functions with \ most of the time (inspired by
LaTeX) :
\transparent{Voice.Stem}
\globalStaffSize{13}
\fontSize{14}
\setStencil{Voice.NoteHead, cross} (or even better, \setNotehead{cross} )
or any other syntax, but the thing is to make it constant.
The inconstant syntax to make anything a little outside the ordinary is, in
my humble opinion, the most time wasting feature of LilyPond. The problem is
that we always need to refer to the manual to find the way to write the
tweak, then we always forget how to do it for another score, since all the
tweaks we use have a different syntax.
Also, when doing this, the point would be to keep the names of the functions
as close to the musical terms and to the musical written symbols.
But a little program editor like the LilyPondTool in jEdit makes it much
easier indeed! Maybe that is the solution to the sometimes too complex
syntax of LilyPond.
Also, thanks for the changes in micro-intervals symbols, especially the db
for -eseh!
Frédéric
Note, importantly, that, with the present tuplet syntax, lily handles
all tuplets -- *including broken ones* -- correctly out of the box.
This sort of thing brings Finale and Sibelius screaming to their
knees. (This seems to be an extension of the fact that lily gets one
thing *exceedingly* correct: the duration model of musical time. Out
of the box you can also specify time signatures like 6/15, 5/28, 3/10
and so on, all of which bring other musical notation programs -- with
the the notable exception of SCORE -- to a crashing standstill. Or at
least the last time I bothered to check.)
I've been watching the tuplet discussion with some hesitation. I think
chaning \times to \tuplet is a great idea for the reason that started
the thread: \times is too close to \time. But it seems to me that most
of the suggestions following that initial suggestion begin to confuse
the essential time-scaling function of tuplet brackets (which is their
absolutely core purpose, both in the common practice and now) and
other graphical aspects of the notation such as beaming, grouping (and
even accentuation). Beaming and grouping are terribly important, of
course, but I think that it's best to leave their specification out of
the core tuplet syntax.
More important is to fix the fact that
\times { c8 d e f }
will currently by default print with only a 4 in the tuplet bracket,
which is mathematically wrong; the denominator 5 must appear.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Frédéric Chiasson wrote:
My point when I started this topic was not to change the whole
definition of the \times function. In fact, I think the function works
quite well as it is. I was mostly talking about improving the
interface - i.e . the words and the syntax we use to call the
functions - to make it more intuitive, especially for a
non-programmer. The \times function was an example among other. I was
proposing to change it to \tuplet x:y, simply because it is closer to
the musicians' language (tuplet), and it reflects more the result we
see and we would write manually (3:2 or 7:5, even if we have 6
sixteenth-notes for the 7:5 in contemporary music).
The issue that's emerged out of this discussion, apart from the question
of \times / \tuplet, is that some users (including myself) would like to
see a more obvious (intuitive?) way of generating *sequences* of
tuplets. As has been mentioned before, \times 2/3 { a8 a a b b b }
doesn't produce two triplets, as you might expect, but six notes with a
single bracket and a 3 over it - to get the desired result, it's
necessary to add \set tupletSpannerDuration = #(ly:make-moment 1 4). For
new users especially, this is a bit daunting IMO.
Changing \times x/y to \tuplet y:x may be more intuitive for
non-programmer musician, but if they still have to use \set
tupletSpannerDuration = #(ly:make-moment ...), I don't see that you've
gained much.
For this reason, I think Erik's proposal of a \tupletSequence function
makes a lot of sense. (Though \tupletSet is shorter to type. ;-) )
Brett
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
. . . Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
I'm not very fluent in Scheme, so this is a naive question.
I presume that ratios like 3:2 (or 2/3) could be made into some kind of
object type (possibly a moment). So I could imagine that it would be
possible to write a Scheme function definition to cover a syntax like
\tupletSequence m:n #'( {...} {...} ... )
where the first argument is a moment and the second is a list of literal
music expressions. (And I suppose I'm too optimistic about that syntax;
probably those {...} would have to be sprinkled with # or $ or other
spices.) But there are some questions:
1) I don't see how this could accommodate the case where one of the music
expressions *were* a variable reference (\var) or *contained* a variable
reference.
2) Because the syntax \tupletSequence m:n { {...} {...} }
is nicer, it would be good if it could be written that way, but then the
second argument would not be a standard Scheme entity, so I don't see how
Scheme could handle it at all.
I don't really want you to explain to me how the tupletSequence function
would be written in Scheme, as I think that that would wind up being an
exceedingly long answer. My question is only this: with your knowledge of
Scheme, is it clear to you that difficulties (1) (2) are handleable?
Can tupletSequence really be defined in pure Scheme, as long as the parser
is modified to recognize the object m:n or n/m (so that there would exist
a type-verification-name for the object m:n for use in defining Scheme
functions)?
-- Tom
*
On Sat, 6 Jan 2007, Erik Sandberg wrote:
On Friday 05 January 2007 22:53, [EMAIL PROTECTED] wrote:
. . . The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
OK. Thank you for clarifying that. I understand, from your original
remarks, that (here) you have written just \tuplet in the interest of
brevity, and that the full form would be
\tupletSequence 3:2 {{c d e} {{f g} a} b c}
meaning
\tuplet 3:2 {c d e} \tuplet 3:2 {{f g} a} \tuplet 3:2 b \tuplet 3:2 c
yes, that's right.
which implies the following things:
a) tupletSequence is a Scheme function which just breaks up its
subexpressions naively, without any semantic analysis.
b) \tuplet is a real LilyPond function; it is identical to \times,
except that the notation 3:2 (meaning 2/3) would be allowed.
c) People would have to write \tupletSequence m:n { {...} {...} },
not \tuplet m:n { {...} {...} }.
yep, this is right (thanks for expressing it clearly).
d) Any semantic errors in the subexpressions would be reported by the
\tuplet function, not by the \tupletSequence Scheme function.
technically this is not correct (the \tuplet function doesn't detect semantic
errors), but in principle you're right (\tuplet and \tupletSequence actually
only create Music data structures, without performing semantic analysis;
most 'semantic errors' are detected either when these data structures are
further processed into typeset scores, or by the parser before the function
applications)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Staff.VerticalAxisGroup #'Y-extent no longer working in Windows Lilypond 2.11.9??
Hi Everyone,
I've been working with Lilypond 2.11.0 for a while and recently tried
2.11.9.
When running the new version the following statements are ignored
\override Staff.VerticalAxisGroup #'Y-extent = #'(0 . 10).
I've been playing around with getting more even output from Lilypond same
number
of systems per page and the same space between staves.
I've even managed in a Concerto Grosso score to have a seperate different
space
between the concertino groups and ripieno groups all the way through the
piece.
But as stated earlier Staff.VerticalAxisGroup #'Y-extent no longer works.
I've included an example below.
Regards,
Trent Johnston
\version 2.11.0
#(set-global-staff-size 16)
\header {
}
\include english.ly
staffViolin = \new Staff {
\time 4/4
\set Staff.midiInstrument=violin
\key c \major
\clef treble
\relative c'' {
%bar 1
c4 d8. c32 d e8 f g4~
%bar 2
g8 e16 c a'8 f16 d d4 r \break
%bar 3
g4 c8 g16( e) a4. g8
}}
staffCello = \new Staff = cont {
\set Staff.midiInstrument=cello
\key c \major
\clef bass
\relative c {
\override Staff.VerticalAxisGroup #'Y-extent = #'(0 . 20)
%bar 1
c4 g c c8 d
%bar 2
e4 f g g8 f
%bar 3
e2 f4 f8 g
}}
bc = \figuremode {
%bar 1
s1
%bar 2
64 s2.
%bar 3
62 s2
}
\score {
\new StaffGroup
\staffViolin
\staffCello
\context Staff = cont \bc
\layout { }
}
\paper { }
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
