Re: "stacked" tempo indications in one line
Dear David, On 22.04.2013, at 09:29, David Kastrup wrote: >> why not just write > > \tempo "Allegro" 4 = 150 > > and have the default formatting? many thanks for the tip! However, it turns out that this is not enough to circumvent the "stacking" problem - but something like this works beautifully with Lilypond 2.16.1: \override Score.RehearsalMark #'extra-spacing-width = #'(-1 . 1) \override Score.RehearsalMark #'padding = #1.5 ... \mark \default \grace s1 \tempo "Moderato" 4 = 120 I also needed the "extra-spacing-width", the "padding" and (curiously) the "\grace s1" - I found the latter in an older thread of this list. I have attached screenshots with and without the additional lines before \tempo. But is this actually the "approved way" of getting my result? <><> Warm regards, Stefan -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleueler Str. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 E-Mail: voll...@nf.mpg.de http://www.nf.mpg.de smime.p7s Description: S/MIME cryptographic signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lobbying paper follow-up
Am 25.04.2013 14:44, schrieb Janek Warchoł: 2013/4/25 Urs Liska: >Do you know of someone >having actually recovered from a text file suffering from a disk crash - >and not having spent more work than starting again from scratch? Myself, to sme extent. Am 25.04.2013 16:48, schrieb David Kastrup: Far too often. By the way, spotty recovery is the reason that tape Thanks Janek and David for this confirmation. I will probably ask for such confirmations a few times when reviewing my article. Especially when it comes to my judgements on competitor software which are based on - faded and colored - recollections on experiences with software that is _very_ outdated (what would have been my experiences with LilyPond back in 2001?) Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Request for feedback on 'lobbying' paper
Am 21.04.2013 08:14, schrieb Evan Driscoll: (I couldn't find something that presented version control the way I wanted to show it, so I wrote a description. In the unlikely event you want to steal portions of it, feel free; I can drop a creative commons license on it.http://pages.cs.wisc.edu/~driscoll/software/vcs/index.html) Thanks for this. I won't 'steal portions of it', however, but will rather look for an appropriate place (in the revised new version) to link to it. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Request for feedback on 'lobbying' paper
Am 21.04.2013 14:31, schrieb Denis Bitouzé:
Hi,
looks very nice though I currently have no time to read it carefully.
Just two remarks:
1. A table of contents would be nice.
This is on my todo-list. It's not a regular table of contents but one
for a subpart of the whole document (which makes it not instantly
available).
(This tutorial, as well as a few others in preparation and hopefully
many in the future can be typeset as a standalone document or as part of
a compilation book).
2. I guess listings are typeset thanks to the "listings" LaTeX
package. IMHO, such listings are much more readable with monospace
characters (such as the ones used by most editors). It is easy to
obtain by just addding in your .tex preamble:
\lstset{basicstyle=\ttfamily}
That's what I had earlier, but for some reason XeLaTeX/fontspec isn't
willing to use the bold version of my chosen tt font (Inconsolata) - so
the listings were without syntax highlighting.
I have already done a workaround (by using the default tt font).
Urs
Best regards.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Off-topics : vibrato
Nice code Mark, many thanks. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
MusicXML project platform
Hi all, in order not to let this discussion go asleep again, I set up a GitHub project https://github.com/openlilylib/ly2xml https://github.com/openlilylib/ly2xml/wiki I hope this may become a place to organize ideas and eventually start producing code. As a start I put together a few pages on the Wiki, collecting statments from recent (and some old) discussion. Feel free to chime in, adding, commenting or whatever. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML project platform
On Apr 26, 2013, at 8:59 AM, Urs Liska wrote: > in order not to let this discussion go asleep again, I set up a GitHub project Hi Urs, Good idea. I added the following which I dug up. As well as the link to SXML support in Guile 2.0. -Paul ___ This discussion on LilyPond's issue tracker gives a lot of insights: http://code.google.com/p/lilypond/issues/detail?id=665 Including comment #15 from Jan Nieuwenhuizen: "You may want to look at input/regression/to-xml.ly and scm/to-xml.scm, some old and preliminary work there." Searcing for "to-xml.ly" in the lilypond-devel archive only brings up 5 results, but the file has existed since September 2002 at least: http://lists.gnu.org/archive/html/lilypond-devel/2002-09/msg00199.html ___ One possibility is to follow the example of MIDI file creation/export. This would apparently require working in C++ rather than Scheme or Python. On 10 Jul 2011 Reinhold Kainhofer (who coded the musicxml2ly python script) wrote: "I have rather been thinking about adding MusicXML export like the MIDI export: Create some translator (e.g. a base class Exporter or Xporter to indicate XML, like Performer or Engraver) and subclasses to listen to all the different music events/grobs. That would probably be the most native and probably also easiest implementation of MusicXML export. For example, MIDI creation is relatively simple code-wise (just look at the performer.cc and the audio.cc and midi*.cc files)." >From the following lilypond-devel thread: >http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00398.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML project platform
Am 26.04.2013 16:39, schrieb Paul Morris: On Apr 26, 2013, at 8:59 AM, Urs Liska wrote: in order not to let this discussion go asleep again, I set up a GitHub project Hi Urs, Good idea. I added the following which I dug up. As well as the link to SXML support in Guile 2.0. -Paul Thanks. That's what I intended with the Wiki. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "stacked" tempo indications in one line
Stefan Vollmar wrote: > I also needed the "extra-spacing-width", the "padding" and (curiously) the > "\grace s1" - I found the latter in an older thread of this list. I have > attached screenshots with and without the additional lines before \tempo. But > is this actually the "approved way" of getting my result? For the most part, it doesn't really matter. Both of the images you showed us are acceptable musically, so there's no real "right" or "wrong". The only difference is how they appeal to your aesthetic sense. If your result pleases your aesthetic sense, then go for it. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "stacked" tempo indications in one line
Stefan Vollmar nf.mpg.de> writes: > \override Score.RehearsalMark #'extra-spacing-width = #'(-1 . 1) > \override Score.RehearsalMark #'padding = #1.5 > ... > \mark \default > \grace s1 > \tempo "Moderato" 4 = 120 > > I also needed the "extra-spacing-width", the "padding" and (curiously) > the "\grace s1" - I found the latter in an older thread of this list. > There is an adjustment to #'Y-offset that goes well with what you have above (so that the \tempo is not placed close to the staff *before* the horizontal spacing, which can space notes too widely, only after). http://code.google.com/p/lilypond/issues/detail?id=3279 The default placement rules put the \mark over the barline, and a \tempo at a change in time-signature change directly over the time-signature, and keeps a fixed horizontal spacing between barline and time-signature. With the manual you could figure out to adjust the rules, but that is complicated. It is much simpler to add the grace note, so that in concept the tempo is no longer *at* the time-signature. You can of course write a comment so you remember why the grace is there. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML project platform
It seems to me that the problem (of exporting lilypond to music-xml) is semi-stalled in the stage of identifying dependencies. I'm an enterprise java programmer and we often use dependency graphs to identify task relationships and next steps. I don't know C or Scheme but I'm tempted to try and at least understand the details of everything that needs to be done so it could be organized in terms of steps/tasks/stories/whatever, and maybe put some dependency graphs up on the wiki - would that be helpful? I guess I just have a couple of basic questions - It sounds like the music-stream is an internal structured representation of the music in the input file (generated after the input file is parsed). It contains time-sorted information but not positioning information. Regarding the strategy of converting the music-stream to musicXML first, and then finding other ways to add positioning information later - is that the only viable approach for enabling MusicXML export? Is converting the music-stream to music-xml as a "first step" a true prerequisite to adding positioning information to the musicXML export? If the music-stream does not have sufficient information for musicXML, is it an option to improve the music-stream to contain more of that necessary positioning information? Or what about improving the layout logic to maintain knowledge of the music-stream so the full xml export could be done at that later stage? If we merely export the pure "music-stream" as a first step, are we coding ourselves into a corner? In other words, is that creating technical debt? Is there an argument that another approach is really the "right way"? Is it a hard prerequisite to add support for Guile 2.x to lilypond before we can enable MusicXML export? Finally, is this the best venue to discuss this? I was always assuming that people were already discussing this over on lilypond-devel. Should we move all musicXML discussions over there or to a brand new list? My own sense after reviewing the discussions I've been able to find: I suspect that focusing on music-stream export first is too "half-a-loaf" and would require major rework once we add positioning. And, that re-parsing the input file for positioning information is not as good an option as figuring out how to hook export logic into the lilypond positioning logic itself. It seems the right way is to make the positioning logic maintain knowledge of music-stream. And if sticking to the end-of-life version of guile makes this development unreasonable, we should first focus on lilypond supporting guile-2.x. All that said, I recognize I lack perspective - thanks for any clarifications. Thanks, Curt On Apr 26, 2013, at 7:46 AM, Urs Liska wrote: > Am 26.04.2013 16:39, schrieb Paul Morris: >> On Apr 26, 2013, at 8:59 AM, Urs Liska wrote: >> >>> in order not to let this discussion go asleep again, I set up a GitHub >>> project >> Hi Urs, Good idea. I added the following which I dug up. As well as the >> link to SXML support in Guile 2.0. >> -Paul > Thanks. That's what I intended with the Wiki. > > Urs > > ___ > 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: MusicXML project platform
Am Freitag, den 26.04.2013, 13:31 -0700 schrieb Curt: > It seems to me that the problem (of exporting lilypond to music-xml) > is semi-stalled in the stage of identifying dependencies. Yes. And in the situation that those who are the knowledge and insight to move this on don't have the capacity to do so. > I'm an enterprise java programmer and we often use dependency graphs > to identify task relationships and next steps. > > I don't know C or Scheme but I'm tempted to try and at least > understand the details of everything that needs to be done so it could > be organized in terms of steps/tasks/stories/whatever, and maybe put > some dependency graphs up on the wiki - would that be helpful? I guess this would be very helpful. In fact anything that could lead to a situation where people are able to write actual code would be very helpful. > > I guess I just have a couple of basic questions - > > It sounds like the music-stream is an internal structured > representation of the music in the input file (generated after the > input file is parsed). It contains time-sorted information but not > positioning information. I think this is correct. > > Regarding the strategy of converting the music-stream to musicXML > first, and then finding other ways to add positioning information > later - is that the only viable approach for enabling MusicXML export? I'm not sure if I don't understand you or if you have misunderstood something in the discussion. The idea of parsing the input files doesn't have anything to do with positioning information - there is even less positioning information in the input file than in the music stream (if you'd consider timing information as positioning information, just for the context). Parsing the input file(s) should retrieve information such as titles, maybe the general \paper variables. Maybe stuff like instrumentNames are easier to retrieve there (don't know). And if it is important to know about transposition this would have to be got from the input (I mean: if the MusicXML file should know about the fact that some music is the result of a transposition). > Is converting the music-stream to music-xml as a "first step" a true > prerequisite to adding positioning information to the musicXML export? Probably not. Practically this is the result of the consideration that this is a goal with a halfway realistic scope, so it could be tackled at all. There is more or less unspoken agreement that a fundamental solution would be preferrable but that there absolutely is nobody capable of doing that. Or to be more precise: There is no perspective on someone being so interested in it to raise/give so much money that there would be enough manpower to be set up. Maybe it could actually help if someone volunteers to analyze the situation and organize the stuff to a clear picture. Maybe this results in the option to start work on rather small steps that one knows will make sense in the big picture. > > If the music-stream does not have sufficient information for musicXML, > is it an option to improve the music-stream to contain more of that > necessary positioning information? Or what about improving the layout > logic to maintain knowledge of the music-stream so the full xml export > could be done at that later stage? I can't judge this because I don't really know about the internal processes. As far as I have understood the relevant discussions at some stage in the whole process the link between graphical objects and the structural cause of the objects is lost. Of course it would be possible to change that, but that would be a rather big operation. > > If we merely export the pure "music-stream" as a first step, are we > coding ourselves into a corner? In other words, is that creating > technical debt? Is there an argument that another approach is really > the "right way"? I have no idea because I have no experience with largescale design decisions. > > Is it a hard prerequisite to add support for Guile 2.x to lilypond > before we can enable MusicXML export? As far as I have understood: no. If I'm right there are just some Scheme/XML utilities available that depend on it. The fact that LilyPond as a whole hasn't move to Guile 2.x is another topic. > > Finally, is this the best venue to discuss this? I was always > assuming that people were already discussing this over on > lilypond-devel. Should we move all musicXML discussions over there or > to a brand new list? My intention with setting up this 'project' was to set up a dedicated place for it. Maybe moving to lilypond-devel would be leave too many people out. I have the impression that the people on lilypond-devel just can't afford to give this project the attention it would need to overcome the 'semi-stall'. Urs > > My own sense after reviewing the discussions I've been able to find: > > I suspect that focusing on music-stream export first is too > "half-a-loaf" and would require major rework once we add positioning.
Re: Request for feedback on 'lobbying' paper
Urs Liska writes: > ... for some reason XeLaTeX/fontspec isn't > willing to use the bold version of my chosen tt font (Inconsolata) - > so the listings were without syntax highlighting. > I have already done a workaround (by using the default tt font). Inconsolata originally had no bold. A bold weight has been added - do you have the newest version? http://code.google.com/p/googlefontdirectory/source/browse/ofl/inconsolata/ -- David R ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML project platform
On Apr 26, 2013, at 4:31 PM, Curt wrote: > My own sense after reviewing the discussions I've been able to find: > > I suspect that focusing on music-stream export first is too "half-a-loaf" and > would require major rework once we add positioning. And, that re-parsing the > input file for positioning information is not as good an option as figuring > out how to hook export logic into the lilypond positioning logic itself. It > seems the right way is to make the positioning logic maintain knowledge of > music-stream. I hear your concern, but as I understand it the music stream is the closest that the music data in LilyPond gets to the structure and level of abstraction of a MusicXML file. (MusicXML 1.0 included no positioning/layout info, which was then added at 2.0, so in a sense we could follow that progression as well, targeting 1.0 first.) So that is why people who know the internals of LilyPond are recommending this approach. Especially, Han-Wen: "you would probably have to use some sort of dual approach, where you store the stream, label each event, and then you trace back the grobs during output stage to their originating events. You can use the ordering from the stream to output the XML elements in the correct order." I take it that the music stream has the order that is needed for the XML file, and that order is no longer present once the stream is converted to grobs and their positioning is determined. So use the stream's order as the framework, and then trace the grobs to their originating events in the stream in order to add positioning after it is determined.[1] This approach has the big advantage that you can do a first iteration without the positioning info and get a lot more benefit for a lot less effort. And one of the biggest constraints here is the volunteer labor force when there are a lot of other areas that are being worked on by only a few people. One of the key variables is how important is having the positioning data? In my mind it is not really that important relative to having an export of the basic musical data. Positioning is icing on the cake. In some cases it may not be used at all, as with a publisher who will do their own custom positioning anyway, or in Braille notation. That's my understanding at least, but I'm no expert. At any rate, I imagine that your insights in organizing, identifying dependencies, tasks, etc, might help. Cheers, -Paul [1] After the music stream data goes to the various engravers and is converted into graphics (grobs). So a note from the input file that has a pitch and duration is converted into separate grobs of a notehead, a stem, a flag, etc, and only at that point is the positioning determined in relation to other grobs. Hence as Mike Solomon said: "there is not a one-to-one correspondence between events in the music stream and musical objects created." ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
the question of triplets
Ok. I understand how triplets work. I've played them often enough lol! but in lily pond according to the manual it says it's written in a fraction. That's the part I don't get. I'm very horrible at math so is there a way to comprehend these triplets. I think they are eighth notes if I hear the recording correctly. I do not have a copy of the brailled piano piece yet so I'm not sure. Any tips? This thing is due by may 10th but I'm hoping I can get this done minus the repeats. roar. Take care all. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: the question of triplets
On Apr 26, 2013, at 6:56 PM, Sarah k Alawami wrote:
> Ok. I understand how triplets work. I've played them often enough lol! but in
> lily pond according to the manual it says it's written in a fraction. That's
> the part I don't get. I'm very horrible at math so is there a way to
> comprehend these triplets. I think they are eighth notes if I hear the
> recording correctly. I do not have a copy of the brailled piano piece yet so
> I'm not sure.
>
> Any tips? This thing is due by may 10th but I'm hoping I can get this done
> minus the repeats. roar.
> Take care all.
A note in a quarter note triplet is actually 2/3 of a quarter note, so that the
three notes in the triplet equal two beats ( 2/3 + 2/3 + 2/3 = 6/3). Because
of that, triplets are written in LilyPond as:
\times 2/3 { c4 d4 e4 }
Hope this is what you are asking about!
Tim
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: the question of triplets
Sarah k Alawami writes:
> Ok. I understand how triplets work. I've played them often enough lol!
> but in lily pond according to the manual it says it's written in a
> fraction. That's the part I don't get. I'm very horrible at math so is
> there a way to comprehend these triplets.
Before version 2.17.11, the syntax is
\times 2/3 { c8 d e }
meaning that each written eighth note takes only two thirds of the time
that an eighth note usually would take.
That's too mathematical not just for you. With version 2.17.11, the
documented and recommended syntax has changed to
\tuplet 3/2 { c8 d e }
which means that you get three tuplets in the time of two ordinary
notes.
Both are just different ways of saying the same, but apparently the
second way is much more natural to people. So if you are using a
version of LilyPond earlier than 2.17.11, use \times and remember that
the fraction is just opposite of what you'd think it should be.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: the question of triplets
lol. Yeah I'll stick with I think it's v 2.16 or something like that until that
2.17 gets released to the public as I'm not quite ready to upgrade my scores
lol!
Tc all.
On Apr 26, 2013, at 6:05 PM, Andrew Bernard wrote:
> Hi from Australia!
>
> You he not given enough information here, because 'triplets' covers a lot of
> cases. But usually it is three notes in the time of two, so the fraction to
> use with \times is 2/3. If you use later versions of lilypond such as 2.17,
> they introduced a better notation which is \tuplet where you can say \tuplet
> 3/2 { ... } which is easier to understand. \times makes the musical time
> duration multiplied by the fraction. \tuplet expresses the idea as musicians
> think about it. You can have \tuplet 5/4 or anything, \tuplet 12/7 for
> example, but you can do the same with \times.
>
> Without looking at your score or hearing the music, I can't help you much
> more.
>
> HTH
>
> Andrew
> Melbourne, Australia
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
