Re: midi panorama
It's a pitty. I thinks it would be useful to have a feature allowing to type in directly midi-commands in Lilypond source-code. I thinks, this wouldn't be too complicated to implement. 2012/6/2 Janek Warchoł > On Sat, Jun 2, 2012 at 11:20 AM, Stefan Thomas > wrote: > > Dear community, > > is it possible to adjust the midi-panorama within lilypond's source code? > > As far as i know this isn't possible, unfortunately :( > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilybin editor
Hoping lilybin author read this. > > From: Martin Tarenskeen >To: MING TSANG >Sent: Sunday, June 3, 2012 5:13:49 AM >Subject: Re: Lilybin editor > > > >On Sat, 2 Jun 2012, MING TSANG wrote: > >> >> Hi Trevor, >> >> Just want to know is lilybin.com is permanently down. If not when it will >> be available? I missed the web page. BTW, when it up again will it contains >> the request that a midi file also available to down other then the pdf file. > >+1 > >I also think lilybin.com was a great idea with lots of future potential , and >would like to see it available again soon and development continued. > >Is the guy(s) behind lilybin reading this list ? > >-- >MT > > >___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 30/05/12 02:12, Han-Wen Nienhuys wrote: One of the problems of LilyPond is that C++ had very poor support for things we desperately need: reflection, automatic memory management and callbacks. How about D? http://dlang.org/ This seems to me to be a great choice for much of LP's needs. C/C++ like core syntax (you can write pretty much pure C when you need to for specificity or efficiency), but with a much more elegant OO syntax than C++; automatic memory management; support for LISP-like and functional programming; much more readily suited for writing multi-threaded code; ... Their string mixin concept looks like it might also be very useful for LP: http://dlang.org/mixin.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
stem across voices
Hi, can you tell me what's the "meaning" of a stem which connects a note in a voice to a rest (?) in another voice? See image attached. Is it good output? (I think it's been engraved in Finale) If so, how can I get it in LilyPond? Thanks, Federico <>___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Joseph Rushton Wakeling writes: > On 30/05/12 02:12, Han-Wen Nienhuys wrote: >> One of the problems of LilyPond is that C++ had very poor support for >> things we desperately need: reflection, automatic memory management >> and callbacks. > > How about D? > > http://dlang.org/ > > This seems to me to be a great choice for much of LP's needs. C/C++ > like core syntax (you can write pretty much pure C when you need to > for specificity or efficiency), but with a much more elegant OO syntax > than C++; automatic memory management; support for LISP-like and > functional programming; much more readily suited for writing > multi-threaded code; ... > > Their string mixin concept looks like it might also be very useful for LP: > http://dlang.org/mixin.html How about first getting C++/Scheme right? As I already explained, cleaning up the mess of layers and control flow will a) give a better basis for judging that approach b) make it easier to migrate individual layers to something else if desired Take a look at Goops: it offers a lot of the things the C++ class system does, with reasonable performance and much better reflection and extensibility. I am currently working on moving the property/event system there, and one will have to see what the performance impact on that will be. It's all nice to throw all sort of language names into the ring, but as long as the architecture of LilyPond is one incoherent mess, porting it is not going to clean it up. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Federico Bruni writes: > Hi, > > can you tell me what's the "meaning" of a stem which connects a note > in a voice to a rest (?) in another voice? > See image attached. There is no rest to be seen. There are just two voices which share some noteheads. Also there is one glissando between two notes. > Is it good output? (I think it's been engraved in Finale) > If so, how can I get it in LilyPond? Your description does not match the image, so it is hard to tell what you want. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Il 03/06/2012 15:20, David Kastrup ha scritto: Federico Bruni writes: Hi, can you tell me what's the "meaning" of a stem which connects a note in a voice to a rest (?) in another voice? See image attached. There is no rest to be seen. There are just two voices which share some noteheads. Also there is one glissando between two notes. I'm referring to the third beat of the bar. I'm wondering what the author means with that stem which connects the F in second voice to the beam in first voice. Yes, you are right: they are sharing the same notehead. But I think it's wrong: only one voice can play that note. Probably the author should have used a (spacer) rest in first voice? Sorry, I don't have any education in musical notation, my explanations will sound weird ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Hi Federico, On Sun, Jun 3, 2012 at 8:51 AM, Federico Bruni wrote: > Il 03/06/2012 15:20, David Kastrup ha scritto: > > Federico Bruni writes: >> >> Hi, >>> >>> can you tell me what's the "meaning" of a stem which connects a note >>> in a voice to a rest (?) in another voice? >>> See image attached. >>> >> >> There is no rest to be seen. There are just two voices which share some >> noteheads. Also there is one glissando between two notes. >> >> > I'm referring to the third beat of the bar. > I'm wondering what the author means with that stem which connects the F in > second voice to the beam in first voice. > > Yes, you are right: they are sharing the same notehead. > But I think it's wrong: only one voice can play that note. > Probably the author should have used a (spacer) rest in first voice? > This sort of notation is very common. Rather than notating only what is physically possible for the player, the notator tries to show the musical sense of the passage. So, here, we have two voices, and the notator is trying to show each voice completely. At this point, the two voices converge on the same pitch. (If this were scored for two instruments, both would touch that note together.) HTH, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
On Sun, Jun 3, 2012 at 3:51 PM, Federico Bruni wrote:
> I'm referring to the third beat of the bar.
> I'm wondering what the author means with that stem which connects the F in
> second voice to the beam in first voice.
>
> Yes, you are right: they are sharing the same notehead.
> But I think it's wrong: only one voice can play that note.
> Probably the author should have used a (spacer) rest in first voice?
>
> Sorry, I don't have any education in musical notation, my explanations will
> sound weird
This is a correct engraving.
Only one sound is to be played.
This notation means
"there's a melody going on like that:
\relative c {
\key g \major
e8 [( f)] f' a, f f'~ f4
}
and by the way, there's a bass line like this
\relative c {
\key g \major
\voiceTwo
e4 f f f
}
And atually, some of the sounds are shared".
hth,
Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Il 03/06/2012 16:04, David Nalesnik ha scritto: This sort of notation is very common. Rather than notating only what is physically possible for the player, the notator tries to show the musical sense of the passage. So, here, we have two voices, and the notator is trying to show each voice completely. At this point, the two voices converge on the same pitch. (If this were scored for two instruments, both would touch that note together.) Thanks David (and Janek), it makes sense to me now ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
\voiceOne and placement of slur (close to noteheads)
This question is related to a bug report I sent some hours ago:
http://lists.gnu.org/archive/html/bug-lilypond/2012-06/msg00022.html
Try to compile the attached file with 2.14.2 and 2.15.39 or git version.
You'll see that in latest version the slurs connect noteheads, even if
\voiceOne is specified. I like this output (even if it breaks the slurs
position in TabStaff).
However, as soon as a beaming appears, the slurs go up the beams and
away from noteheads. I guess that this is due to \voiceOne.
There's a way to keep the slurs close to noteheads? Is it a good
intended output?
When I write polyphonic music I must specify \voiceOne and \voiceTwo in
order to avoid clashes.
Thanks,
Federico
\version "2.15.40"
first = \relative c' {
b8( c)
% uncomment and the hammer-on "bug" goes away
b16 c cis d
}
second = \relative c {
d8( e)
%d16 dis e f
}
\score {
\new StaffGroup <<
\new Staff = "staff" <<
\context Voice = "first voice" { \clef "G_8" \voiceOne \first }
\context Voice = "second voice" { \clef "G_8" \voiceTwo \second }
>>
\new TabStaff = "tab" <<
\context TabVoice = "tab first voice" { \clef "moderntab" \voiceOne \first }
\context TabVoice = "tab second voice" { \clef "moderntab" \voiceTwo \second }
>>
>>
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
David Nalesnik writes: > This sort of notation is very common. Rather than notating only what > is physically possible for the player, the notator tries to show the > musical sense of the passage. It's not actually even physically impossible: most instruments allow you more than a binary tone-on/tone-off, and even with a binary tone-on/tone-off, you have the choice to play notes with different duration. In the case of the guitar, you would pick the note as loud (and using the same picking fingers) as with the faster voice, but let the note sustain in line with the slower voice while picking the next note of the faster voice just as loud as the previous one. "voicing" is an important and advanced skill for most instruments: guitar, violin, pianoforte (much more so than with plucked keyboards like harpsichord and spinett), accordion: the important thing is to lend each _voice_ a consistent character (loudness, articulation) independent from the distribution across fingers, hands, strings, and even given colocation with another voice on the same notes. Of course, string instruments have a bit more voicing possibilities by the decision which string to take. The violin works of Bach offer interesting voicings. A rather prominent (and mostly monophonic but still multivoice) example is the first motion from the violin solo partita 3: the voicing made very explicit in the autograph can be straightforwardly mapped to different strings. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
2012/6/3 Federico Bruni :
> Il 03/06/2012 16:04, David Nalesnik ha scritto:
>
>> This sort of notation is very common. Rather than notating only what is
>> physically possible for the player, the notator tries to show the
>> musical sense of the passage.
If you'd try to notate exactly what's to be heared, the readability is worse.
-> attached PNG
2012/6/3 Janek Warchoł :
> This is a correct engraving.
Not really.
It is physically _impossible_ to play
\relative c { \clef "G_8" <<{ e,8 [f] } \\ { e4}>> }
on a common six-string guitar. (first beat of the bar)
-Harm
<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
David Kastrup writes: > "voicing" is an important and advanced skill for most instruments: > guitar, violin, pianoforte (much more so than with plucked keyboards > like harpsichord and spinett), accordion: the important thing is to > lend each _voice_ a consistent character (loudness, articulation) > independent from the distribution across fingers, hands, strings, and > even given colocation with another voice on the same notes. Of > course, string instruments have a bit more voicing possibilities by > the decision which string to take. Oh, by the way: voicings are one of the things that tend not to make it through Midi. An excellent human-played Midi on good equipment might preserve some of it, but it is recognizable pretty much only by humans and too subtle to pick up by converters. And usually it is more recognizable in life since most instruments offer a subtle control of attack and decay character that is not reflected in Midi. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
On Sun, Jun 3, 2012 at 4:45 PM, Thomas Morley
wrote:
> 2012/6/3 Janek Warchoł :
>> This is a correct engraving.
>
> Not really.
> It is physically _impossible_ to play
> \relative c { \clef "G_8" <<{ e,8 [f] } \\ { e4}>> }
> on a common six-string guitar. (first beat of the bar)
indeed - i overlooked that.
Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Janek Warchoł writes:
> On Sun, Jun 3, 2012 at 4:45 PM, Thomas Morley
> wrote:
>> 2012/6/3 Janek Warchoł :
>>> This is a correct engraving.
>>
>> Not really.
>> It is physically _impossible_ to play
>> \relative c { \clef "G_8" <<{ e,8 [f] } \\ { e4}>> }
>> on a common six-string guitar. (first beat of the bar)
>
> indeed - i overlooked that.
Well, the voices are supposedly shown "conceptually" and the slide is
supposed to preserve a bit of the original attack on the low note. But
the tie to the second quarter note is not consistent with that
interpretation: with that voicing, you'd usually pick the second quarter
again (usually with the thumb), and then there would not be a tie.
So this is a rather strained map between musical content, physical play,
and notation.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Am 03.06.2012 16:45, schrieb Thomas Morley:
Not really.
It is physically _impossible_ to play
\relative c { \clef "G_8"<<{ e,8 [f] } \\ { e4}>> }
on a common six-string guitar. (first beat of the bar)
-Harm
it took me approx. 3 seconds to change the tuning of the 6-th string
down to d - then it was perfectly playable - even the glissando makes
sense!
cheers
Eluze
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
2012/6/3 Eluze :
>
>
> Am 03.06.2012 16:45, schrieb Thomas Morley:
>
>>
>> Not really.
>> It is physically _impossible_ to play
>> \relative c { \clef "G_8"<<{ e,8 [f] } \\ { e4}>> }
>> on a common six-string guitar. (first beat of the bar)
>>
>> -Harm
>
>
> it took me approx. 3 seconds to change the tuning of the 6-th string down
> to d - then it was perfectly playable - even the glissando makes sense!
> cheers
> Eluze
The scordatura is not the problem. :)
But you can't hold the e on the 6th string as a crotchet.
-Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Invalid URLs in the lilypond-user Digests
I have a question about the format of the lilypond-user Digests, namely, about the form of URLs given for scrubbed attachments, such as the last line below. The curious thing about that URL - and, indeed, all such URLs in the Digests - is that it is not a valid link. Clicking on it will always result in: > Not Found > > The requested URL > /archive/html/lilypond-user/attachments/20120603/66923ef3/attachment.jpg was > not found on this server. How do people deal with this? Is there something I can do to get Digests with valid URLs? (Reply not sent to Federico Bruni as it is not really a reply to him.) > Message: 5 > Date: Sun, 03 Jun 2012 15:15:17 +0200 > From: Federico Bruni > To: lilypond-user > Subject: stem across voices > Message-ID: <4fcb6365.5060...@gmail.com> > Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" > > Hi, > > can you tell me what's the "meaning" of a stem which connects a note in > a voice to a rest (?) in another voice? > See image attached. > > Is it good output? (I think it's been engraved in Finale) > If so, how can I get it in LilyPond? > > Thanks, > Federico > -- next part -- > A non-text attachment was scrubbed... > Name: stem-cross-voices.jpg > Type: image/jpeg > Size: 41996 bytes > Desc: not available > URL: > <http://lists.gnu.org/archive/html/lilypond-user/attachments/20120603/66923ef3/attachment.jpg> ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 03/06/12 14:17, David Kastrup wrote: How about first getting C++/Scheme right? As I already explained, cleaning up the mess of layers and control flow will a) give a better basis for judging that approach b) make it easier to migrate individual layers to something else if desired Don't get me wrong; I'm not proposing a rewrite on the spot or even in the near future. It's just that if there _is_ at some point a desire to consider a bottom-up rebuild with a new language or framework, D is probably one to take seriously, as it offers the power and flexibility of LISP and functional languages while having a very friendly and usable syntax. But in the short term at least, I completely agree with you about getting the C/Scheme combo right (if I understood your earlier email correctly, the desire is to remove as much C++ as possible). Take a look at Goops: it offers a lot of the things the C++ class system does, with reasonable performance and much better reflection and extensibility. I am currently working on moving the property/event system there, and one will have to see what the performance impact on that will be. I'll give it a look. It's all nice to throw all sort of language names into the ring, but as long as the architecture of LilyPond is one incoherent mess, porting it is not going to clean it up. Agree about architecture being the priority. I can make no promises as my LP-wards free time is sporadic, but I would like to assist here if I can. That said, I didn't make the language suggestion casually. One of the issues with Scheme is that although it's powerful it's also an unfamiliar and not-so-easy-to-grasp scripting syntax when compared with the languages lots of people are familiar with. D has the advantage of being high-performance (as fast as C/C++ in my experience), having a syntax which is easy to switch to from C/C++/Java/C#/etc., but also having the functional/LISP-like constructs needed by LilyPond. It would be a major breaking change, though, so not to be done without very careful consideration. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Am 03.06.2012 17:18, schrieb Thomas Morley:
2012/6/3 Eluze:
Am 03.06.2012 16:45, schrieb Thomas Morley:
Not really.
It is physically _impossible_ to play
\relative c { \clef "G_8"<<{ e,8 [f] } \\ { e4}>> }
on a common six-string guitar. (first beat of the bar)
-Harm
it took me approx. 3 seconds to change the tuning of the 6-th string down
to d - then it was perfectly playable - even the glissando makes sense!
cheers
Eluze
The scordatura is not the problem. :)
But you can't hold the e on the 6th string as a crotchet.
-Harm
I've seen many such "incorrect" notation - maybe the typesetter wasn't
playing that instrument himself or overlooked that, maybe the composer
wanted to stress the quarter rhythm of the bass… (this has been said in
former replies)
Eluze
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Joseph Rushton Wakeling writes: > On 03/06/12 14:17, David Kastrup wrote: >> How about first getting C++/Scheme right? As I already explained, >> cleaning up the mess of layers and control flow will >> >> a) give a better basis for judging that approach >> b) make it easier to migrate individual layers to something else if >> desired > > Don't get me wrong; I'm not proposing a rewrite on the spot or even in > the near future. It's just that if there _is_ at some point a desire > to consider a bottom-up rebuild with a new language or framework, D is > probably one to take seriously, as it offers the power and flexibility > of LISP and functional languages while having a very friendly and > usable syntax. > > But in the short term at least, I completely agree with you about > getting the C/Scheme combo right (if I understood your earlier email > correctly, the desire is to remove as much C++ as possible). I don't want to remove "as much C++ as possible". That's about as useful as to remove "as much C as possible" from Emacs. The point is to consider C++ as the building language for primitives, and tie together the primitives in Scheme. At the current point, most of the control flow is inaccessible from the Scheme layer. That's not helpful for extending, and it is not helpful for understanding LilyPond from a user perspective. The C++ layer most certainly is important as underpinnings, but you can't understand LilyPond from the Scheme perspective because not just functionality/performance but also logic and control flow is tied to a large degree into that layer: you would not dare working with "call-with-current-continuation", and most of the time, the Scheme stacktrace (and debugger) is not significant for finding out what happens. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Hi all, As a composer, I can say that I often use "incorrect" notation in order to highlight voice-leading and intentions regarding articulation/stress/etc. In particular, my Chaconne for unaccompanied violin has many "unplayable" passages, which sound quite lovely when played "correctly". =) Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
Il 03/06/2012 18:37, Eluze ha scritto:
Am 03.06.2012 17:18, schrieb Thomas Morley:
2012/6/3 Eluze:
Am 03.06.2012 16:45, schrieb Thomas Morley:
Not really.
It is physically _impossible_ to play
\relative c { \clef "G_8"<<{ e,8 [f] } \\ { e4}>> }
on a common six-string guitar. (first beat of the bar)
-Harm
it took me approx. 3 seconds to change the tuning of the 6-th string
down
to d - then it was perfectly playable - even the glissando makes sense!
cheers
in fact it's guitar-open-d tuning
The scordatura is not the problem. :)
But you can't hold the e on the 6th string as a crotchet.
you mean it should be e4. instead of e8~ e4?
this is just a notational issue, it is playable
I guess I'm missing what you mean
-Harm
I've seen many such "incorrect" notation - maybe the typesetter wasn't
playing that instrument himself or overlooked that, maybe the composer
wanted to stress the quarter rhythm of the bass… (this has been said in
former replies)
Yes, I think that's the reason: stress the quarter rhythm of the bass
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
2012/6/3 Federico Bruni : (...) Am 03.06.2012 16:45, schrieb Thomas Morley: >>> But you can't hold the e on the 6th string as a crotchet. >>> > > you mean it should be e4. instead of e8~ e4? > this is just a notational issue, it is playable > I guess I'm missing what you mean (...) Well, there is always a certain difference between exact notation, i.e. writing down what you hear, and the intended meaning, i.e. writing down how it should be understood. As Kieran pointed out before. My point was that it is impossible to play 8 only on the 6th string of a guitar. But that should sound at the second quaver of the example following _exactly_ the notation of your example. Perhaps I'm a too much an inch pincher. Forget about it. -Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 03/06/12 17:44, David Kastrup wrote: I don't want to remove "as much C++ as possible". That's about as useful as to remove "as much C as possible" from Emacs. The point is to consider C++ as the building language for primitives, and tie together the primitives in Scheme. OK, I misinterpreted your remarks somewhat. I had read them as meaning that (besides re-architecting things so that control flow etc. was organized from within Scheme) you wanted to strip out the object-oriented side of things and move that over to Scheme, so that what was currently C++ would be pared back to being fairly pure C. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Joseph Rushton Wakeling writes: > On 03/06/12 17:44, David Kastrup wrote: >> I don't want to remove "as much C++ as possible". That's about as >> useful as to remove "as much C as possible" from Emacs. The point is to >> consider C++ as the building language for primitives, and tie together >> the primitives in Scheme. > > OK, I misinterpreted your remarks somewhat. I had read them as > meaning that (besides re-architecting things so that control flow > etc. was organized from within Scheme) you wanted to strip out the > object-oriented side of things and move that over to Scheme, so that > what was currently C++ would be pared back to being fairly pure C. Well, the code written in C++ needs to stay manageable as well. If you take a look at Goops, you have considerable leeway for adding a Scheme OO layer modeled along an existing C++ layer. As I said, I am going through the context/property system, and I don't intend to change the C++ code using it significantly (well, there will be a number of macros redefined and obviously things like context-property.cc and other stuff _implementing_ those interfaces are bound to go). But there are things like a "let's implement the Ambitus engraver as an example in Scheme" project that are sort of an academic exercise because of hand-cranking a lot of stuff. And there are a few examples in snippets and/or regtests that actually use Goops, and they are ad-hoc-ing some artificial and arbitrary structures together that make understanding matters harder for the average reader. If the context/property system has a _natural_ Goops/Scheme interface, then you have an object oriented _framework_ you can get into. Doing a full-featured engraver in Scheme, including interfaces, grobs, mobs, event-classes, whatever, is then just an exercise of following existing practice and using existing structures and mechanisms. You don't need to make it all up. Learning how to _use_ stuff is orders of magnitude easier than learning how to _invent_ stuff. Most importantly: you don't need to make design decisions. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \voiceOne and placement of slur (close to noteheads)
Am 03.06.2012 16:42, schrieb Federico Bruni: This question is related to a bug report I sent some hours ago: http://lists.gnu.org/archive/html/bug-lilypond/2012-06/msg00022.html Try to compile the attached file with 2.14.2 and 2.15.39 or git version. You'll see that in latest version the slurs connect noteheads, even if \voiceOne is specified. I like this output (even if it breaks the slurs position in TabStaff). However, as soon as a beaming appears, the slurs go up the beams and away from noteheads. I guess that this is due to \voiceOne. There's a way to keep the slurs close to noteheads? Is it a good intended output? IIUC, the only way to keep the slurs close to the note heads is to specify \slurDown | \slurUp *after* \voiceOne | \voiceTwo, or you specify the stem direction by "_" or "^", respectively. b8^( c) or b8_( c) But in your specific case, the slurs will overlap in the space between upper and lower voice, so this looks o.k. only in cases where the two voices have a suitable distance. Elaine Gould uses both ways of stem placement according to the distance of the two voices and the readability in presence of other signs and symbols like fingerings, accents etc. HTH, Marc When I write polyphonic music I must specify \voiceOne and \voiceTwo in order to avoid clashes. Thanks, Federico ___ 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: midi panorama
On Sun, Jun 3, 2012 at 11:12 AM, Stefan Thomas wrote: > It's a pitty. > I thinks it would be useful to have a feature allowing to type in directly > midi-commands in Lilypond source-code. It would be better to have Lily commands for things like panorama, i think. > I thinks, this wouldn't be too complicated to implement. i don't know. cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
> My point was that it is impossible to play 8 only on the 6th > string of a guitar. > But that should sound at the second quaver of the example following > _exactly_ the notation of your example. > just another thought - if these notes have originally been written for another instrument - let's say for a piano - and later it was transcribed: does it not make sense sense to keep the original quarter (perhaps one could parenthesize it…)? I believe the quarter rhythm is better marked with a quarter note in analogy to the following quarters. Eluze -- View this message in context: http://old.nabble.com/stem-across-voices-tp33953167p33954604.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: custom compound time signature
Thank you so much! This code worked perfectly. You were of course absolutely
right about the context for \numericTimeSignature...I can't believe I didn't
spot that myself!
I have not worked with Scheme before and I would like to start learning how
to write advanced tweaks for Lilypond as well as functions to automate some
of the writing of music expressions. So far I've noticed on my own some
differences (such as #(define... for music expression functions, but
#(lambda... for dealing with grobs) but I haven't found a good resource to
help me learn more about these details. I'm a musician/musicologist with
only a little programming experience.
I'm still using 2.12.3 because that is what the Lilypond download site lists
as the latest stable version for Windows. Where can I find 2.14.2, and how
could I install it while keeping 2.12.3 in case I need to fall back to the
earlier version?
Many thanks!
harm6 wrote:
>
> 2012/6/2 diekunstderfuge :
>>
>> Hi all,
>>
>> I'm trying to achieve the compound time signature seen in the image here:
>> http://old.nabble.com/file/p33950720/custom_time_signature.png
>>
>> As you can see, it's meant to represent 3 bars of 2/4 grouped together as
>> one bar. My plan was to write it as one bar of 3/2 and then override the
>> time signature stencil.
>>
>> First, I've used this snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=272
>> http://lsr.dsi.unimi.it/LSR/Item?id=272 ) to create a "dummy" staff with
>> only the time signatures. (For some reason, \numericTimeSignature does
>> not
>> seem to work inside of the TimeSig context. Does anyone know why?)
>
> Have a look at /ly/property-init.ly. where \numericTimeSignature is
> defined:
> numericTimeSignature = \override Staff.TimeSignature #'style = #'numbered
>
> But now you're using a new custom-defined context: "TimeSig"
> Replace Staff with TimeSig and it will work.
>
>> This snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=609
>> http://lsr.dsi.unimi.it/LSR/Item?id=609 ) prints only the numerator of
>> the
>> time signature, which I need to get the "3". I do not know how to combine
>> this with a compound time signature
>
> Try:
>
>
>
> \version "2.14.2"
>
> customTimeSigI =
> \once \override TimeSig.TimeSignature #'stencil =
>#(lambda (grob)
> (grob-interpret-markup grob
> (markup
> #:vcenter #:number "3"
> #:vcenter "x"
> #:override '(baseline-skip . 0) #:number (#:column ("2" "4")
>
> \layout {
> \context {
> \type "Engraver_group"
> \consists "Time_signature_engraver"
> \consists "Axis_group_engraver"
> \name "TimeSig"
> \override TimeSignature #'font-size = #2
> \override TimeSignature #'break-align-symbol = ##f
> \override TimeSignature #'X-offset =
> #ly:self-alignment-interface::x-aligned-on-self
> \override TimeSignature #'self-alignment-X = #CENTER
> %\override TimeSignature #'self-alignment-X = #LEFT
> \override TimeSignature #'after-line-breaking =
> #shift-right-at-line-begin
> }
> \context {
> \Score
> \accepts TimeSig
> }
> \context {
> \Staff
> \remove "Time_signature_engraver"
> }
> }
>
> timeSignatures = {
> \override TimeSig.TimeSignature #'style = #'numbered
> \time 2/4
> s2
> \time 3/4
> s2.
> \time 4/4
> s1
> \customTimeSigI
> \time 6/4
> \set Score.beatStructure = #'(2 2 2)
> s1.
> }
>
> \score {
> <<
> \new TimeSig \timeSignatures
> \new Staff \relative { c'2 c2. c1 c1. \repeat unfold 12 { c8 } }
> \new Staff { a2 a2. a1 a1. a1.}
> >>
> }
>
>
>
>> Controlling beaming behavior, often a concern with compound time
>> signatures,
>> is not important as the TimeSig staff displays only time signatures.
>
> I added the "2.14.2"-command \set Score.beatStructure = #'(2 2 2)
> Delete it if you want or replace it with an "2.12.3"-command.
> But please note: it _will_ affect the score.
>
>> I am using 2.12.3.
>
> Why do you use this outdated version?
> Well, some time ago the LSR was on "2.12.3" and that was the reason
> why I didn't delete this version, while installing the newer stable
> version and the newest development-version.
> But I'm absolutely sure that the LSR is now on "2.14.2" :)
>
> HTH,
> Harm
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
--
View this message in context:
http://old.nabble.com/custom-compound-time-signature-tp33950720p33955037.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Music function for manual vertical placement of systems and staves
Dear fellow users,
I have managed to design some simple music functions, but I haven't
succeeded with this one.
The score (SATB choral) is short but has a certain complexity (a number of
repeated passages, pronunciation notes under lyrics, large markup text
appearing mid-score, etc.). After getting a lot of help on a number of
issues from the forum (thank you, Harm, in particular!), I wrangled
unsuccessfully with flexible vertical spacing, so I decided to position the
systems and staves manually. I fairly quickly got the result I wanted in
terms of appearance, after a little juggling, but now my file is cluttered
up with code like this:
\overrideProperty #"Score.NonMusicalPaperColumn"
#'line-break-system-details #'((Y-offset . 20)
(alignment-distances . (10 10 10)))
It seemed to me that a darling little music function should be able do the
trick, and hoped to get it to work with syntax something like this:
\SATBVert [SystemVerticalPosition] [SopToAltoStaves] [AltoToTenorStaves]
[TenorToBassStaves]
e.g. \SATBVert #20 #10 #10 #10
I tried to write a function along the following lines, but it didn't work:
SATBVert = #(define-music-function
(parser location sysvert StoA AtoT TtoB)
(number? number? number? number?)
#{
\overrideProperty #"Score.NonMusicalPaperColumn"
#'line-break-system-details
#'( (Y-offset . $sysvert)
(alignment-distances . ($StoA $AtoT $TtoB)))
#})
I'm pretty sure, from what I've read, that what I'm missing is type
predicates, but my tiny and inexperienced brain hasn't discovered or worked
out the syntax for how to include them. (I won't trouble you with
reproducing my failed experiments.) Or maybe there's something else wrong
that I haven't discovered.
If someone could point me in the right direction -- a relevant example would
be great -- I would be very grateful.
Cheers, Philip
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: custom compound time signature
On 12-06-03 04:29 PM, diekunstderfuge wrote: Thank you so much! This code worked perfectly. You were of course absolutely right about the context for \numericTimeSignature...I can't believe I didn't spot that myself! I have not worked with Scheme before and I would like to start learning how to write advanced tweaks for Lilypond as well as functions to automate some of the writing of music expressions. So far I've noticed on my own some differences (such as #(define... for music expression functions, but #(lambda... for dealing with grobs) but I haven't found a good resource to help me learn more about these details. I'm a musician/musicologist with only a little programming experience. I'm still using 2.12.3 because that is what the Lilypond download site lists as the latest stable version for Windows. Where can I find 2.14.2, and how could I install it while keeping 2.12.3 in case I need to fall back to the earlier version? Many thanks! If you go to http://www.lilypond.org/windows.html you'll get a link to 2.14.2 which is the latest stable release, and also where you will find the next stable version, 2.16, due shortly. As to running two versions under Windows, the following is quoted from our mail list: From: "James Lowe" From: "James Lowe" Cc: "Lilypond-User" Sent: Wednesday, July 14, 2010 5:13 PM Subject: RE: Different versions of LilyPond That sounds awfully complicated (and one would question the legality of having multiple installs of the same version of XP on one machine but I haven't read MS's EULA) Can't you just 1. install version 2.12.whatever 2. rename lilypond dir accordingly 3. install ve4rsion 2.13.whatever 4. rename lilypond dir accordingly and just put back the old dir name for the version you want to use. I believe pretty much everything is self-contained. James I think you'll find the change from 2.12 to 2.14 to be pretty painless, although you should run the convert.ly script over the .ly you want to update, or better, use Wilbert Berendsen's Frescobaldi program, where convert-ly is a menu option. Hope this helps! Colin the Elder -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stem across voices
On Sun, 2012-06-03 at 15:15 +0200, Federico Bruni wrote: > Hi, > > can you tell me what's the "meaning" of a stem which connects a note in > a voice to a rest (?) in another voice? > See image attached. > > Is it good output? (I think it's been engraved in Finale) > If so, how can I get it in LilyPond? It's fine. The double stem in guitar music usually indicates harp-legato in the short beamed notes for the written duration of the long note, but with only one eighth note there is no difference whatever between the extra stem and a rest. Depending on who wrote it and when, you might use an eighth rest instead. You can do what you ask by having the note in both parts and merging the heads. IMO if you really have the same note on two strings you should not merge the heads, but there is no such rule. There is also no such thing as an authority on music notation. Regards, daveA ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Music function for manual vertical placement of systems and staves
Hi Philip,
I tried to write a function along the following lines, but it didn't work:
>
> SATBVert = #(define-music-function
>(parser location sysvert StoA AtoT TtoB)
>(number? number? number? number?)
> #{
>\overrideProperty #"Score.NonMusicalPaperColumn"
> #'line-break-system-details
>#'( (Y-offset . $sysvert)
>(alignment-distances . ($StoA $AtoT $TtoB)))
> #})
>
[...]
> If someone could point me in the right direction -- a relevant example
> would
> be great -- I would be very grateful.
>
To insert your arguments into the alist you're overriding, you can do
something like this:
\version "2.15.39"
SATBVert = #(define-music-function
(parser location sysvert StoA AtoT TtoB)
(number? number? number? number?)
#{
\overrideProperty #"Score.NonMusicalPaperColumn"
#'line-break-system-details
#`((Y-offset . ,sysvert)
(alignment-distances . (,StoA ,AtoT ,TtoB)))
#})
(Note the backquote. For more on this syntax, see
http://www.gnu.org/software/guile/manual/html_node/Expression-Syntax.html#Expression-Syntax
)
HTH,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
