how to beam non-tuplets with tuplets?
It seems you can beam together tuplets followed by non-tuplets (v. 2.11):
\times 2/3 {c'16[ c'8 } c'16 c'16]
But beaming together non-tuplets followed by tuplets fails with an
unexpected ']' error:
c'16[ c'16 \times 2/3 {c'16 c'8 } ]
Any known methods/hacks to get the second beaming example to work?
Best regards,
Adam
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
Perhaps two examples - one manually beaming non-tuplets-tuplets and
one manually beaming tuplets-non-tuplets (maybe just the examples
below) - could be added to the 2.11 manual under tuplets? I'd be
happy to write up a little chunk of text if that would help.
Best,
Adam
On 9/10/07, Adam James Wilson [EMAIL PROTECTED] wrote:
Nevermind - I've answered my own question - here it is, for those interested:
r16[ g16 \times 2/3 {r16 e'8] }
Best,
Adam
On 9/10/07, Adam James Wilson [EMAIL PROTECTED] wrote:
It seems you can beam together tuplets followed by non-tuplets (v. 2.11):
\times 2/3 {c'16[ c'8 } c'16 c'16]
But beaming together non-tuplets followed by tuplets fails with an
unexpected ']' error:
c'16[ c'16 \times 2/3 {c'16 c'8 } ]
Any known methods/hacks to get the second beaming example to work?
Best regards,
Adam
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: structure of index
Furthermore, I would like to see entries like \displayLilyMusic: Displaying LilyPond notation \displayLilyMusic: Displaying music expressions rather being structured as follows: \displayLilyMusic: Displaying LilyPond notation Displaying music expressions If at all, it should be \displayLilyMusic: Displaying LilyPond notation, Displaying music expressions otherwise it sticks out far too promimently. I'm not certain if texinfo 4.8 can do that. Werner, do you know? No, sorry. FWIW 4.9 was released on June 29, and the latest beta is 4.9.92, so they might add it before 4.11... 4.11 has been released two days ago. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GTK and LilyPond
Mark Dewey writes: Is it possible to get a distribution of LilyPond that doesn't have the GTK or GTK elements bundled, but rather just relies on the one already installed? That's probably not possible. Windows knows no packaging system, there is no dependency resolving and every package just dumps their stuff in a random place. So, there's no way to be sure that the dependencies are installed with the right versions. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: rearrangement
Hello, from what so far has been discussed I catched somewhat the need is to group the issues more into single topic sections of subsections. For the discussion about the format of the html-docu: I would rather like to have whole subsections downloading than those tiny pages -- I also get lost on them and always have to go at least three steps up until I come again to the contents where I look for another promising section's name. So actually for me also a link to the toc would be sufficient, maybe also one to the index, to be on *every* page. I personally dislike the system that for going from a subsection to the next section demands climbing up one level -- I am probably too much used to reading real books where this kind of strange behaviour doesn't happen. But it might be a texinfo issue that we cannot incluence... About rearranging: I would suggest breaking up chapters (with only one number, like 6, 7, and so on) into smaller chapters in some cases, that is being more specific on the lowest level. For instance I could imagine a chapter Ancient music, and one on educational subjects. At least I don't see why Ancient is instrument specific, so why not put it in 7 from the current suggestion, right after educational and special noteheads. I didn't check the situation now but from the discussion about aligning cadenzas -- I would look for cadenzas either in grace notes (being something additional) or at rhythmic issues. From there we could have a link to a general chapter about aligning... I am also somewhat unpleasant with the current string section in the instrument specific chapter: I would like to see here all those \bowdown, \bowup, \flageolet, \thumb and so on that are in articulations so far -- or at least a link to them. Well, that's already about contents, not only rearranging. I like the text-section, that is a good idea. But going the same way for other stuff as well... Name of chapter 7 should maybe be changed, not everything is about decoration, there are some really important things. Would it be something like polishing, finishing or the like? Sorry for writing so confused, I hope it is still understandable. It's mainly just some thoughts... Greetings Till * 6 Basic musical notation o 6.1 Pitches + 6.1.1 Normal pitches + 6.1.2 Accidentals + 6.1.3 Cautionary accidentals + 6.1.4 Micro tones + 6.1.5 Note names in other languages + 6.1.6 Relative octaves + 6.1.7 Octave check + 6.1.8 Rests + 6.1.9 Skips o 6.2 Affecting multiple pitches + 6.2.1 Clef + 6.2.2 Key signature + 6.2.3 Transpose + 6.2.4 Instrument transpositions + 6.2.5 Ottava brackets o 6.3 Rhythms + 6.3.1 Durations + 6.3.2 Augmentation dots + 6.3.3 Tuplets + 6.3.4 Scaling durations + 6.3.5 Automatic note splitting + 6.3.6 Aligning to cadenzas o 6.4 Meter + 6.4.1 Time signature + 6.4.2 Partial measures + 6.4.3 Unmetered music + 6.4.4 Polymetric notation (alternating) + 6.4.5 Polymetric notation (simultaneous) + 6.4.6 Time administration + 6.4.7 Proportional notation (introduction) + 6.4.8 Automatic beams + 6.4.9 Manual beams + 6.4.10 Feathered beams o 6.5 Bars + 6.5.1 Bar check + 6.5.2 Barnumber check + 6.5.3 Multi measure rests + 6.5.4 Bar lines + 6.5.5 Bar numbers + 6.5.6 Rehearsal marks o 6.6 Polyphony + 6.6.1 Chords + 6.6.2 Stems + 6.6.3 Basic polyphony + 6.6.4 Explicitly instantiating voices + 6.6.5 Collision resolution + 6.6.6 Clusters + 6.6.7 Automatic part combining + 6.6.8 Writing music in parallel * 7 Decorating musical notation o 7.1 Connecting notes + 7.1.1 Ties + 7.1.2 Slurs + 7.1.3 Phrasing slurs + 7.1.4 Laissez vibrer ties + 7.1.5 Grace notes + 7.1.6 Analysis brackets o 7.2 Expressive marks + 7.2.1 Articulations + 7.2.2 Dynamics (absolute) + 7.2.3 Dynamics (crescendi) + 7.2.4 Breath marks + 7.2.5 Trills + 7.2.6 Glissando + 7.2.7 Arpeggio + 7.2.8 Falls and doits o 7.3 Staff notation + 7.3.1 System start delimiters + 7.3.2 Staff symbol + 7.3.3 Hiding staves + 7.3.4 Metronome marks
Re: how to beam non-tuplets with tuplets?
2007/9/11, Adam James Wilson [EMAIL PROTECTED]: Perhaps two examples - one manually beaming non-tuplets-tuplets and one manually beaming tuplets-non-tuplets (maybe just the examples below) - could be added to the 2.11 manual under tuplets? I'd be happy to write up a little chunk of text if that would help. That this is definitely a LSR-worthy tip (I've been looking for such a tip for hours myself). Feel free to add it yourself, I'll be glad to approve it: http://lsr.dsi.unimi.it/ Once you've added it, we could probably just put a LSR link in the manual. Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: length/page-splitting of subsections
Graham Percival wrote: There are two solutions for this: 1) Don't split HTML by into subsections; have one html page per section. 2) Merge many subsections. For example, 6.1 Pitches 6.1.1 Writing pitches(includes 6.1.1, 6.1.2, 6.1.3, 6.1.4, and 6.1.5 in the latest proposal) 6.1.2 Octaves/jumping pitches (includes 6.1.6, 6.1.7, and 7.1.8) 6.1.3 Rests(includes 6.1.9 and 6.10) the names obviously need work. My preference is for 2 -- I can't believe that users want to see articulations, dynamics, and trills on the same HTML page. But as I said, we should probably disregard my opinion on this issue. Yes, merging some selected subsections is probably the best solution. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GTK and LilyPond
2007/9/11, Mark Dewey [EMAIL PROTECTED]: Anyway, whenever I install LilyPond, GIMP doesn't work anymore because of something to do with this. I don't know which GTK applications you're using, but the opposite could be done easily, i.e. standard LilyPond installation, *but* instead of using a GTK installation, you can use a portable version of every other GTK application you need: http://portableapps.com/apps/internet/pidgin_portable http://portableapps.com/apps/graphics_pictures/gimp_portable etc... These applications come with their own bundled GTK, which shouldn't cause any conflict with LilyPond. (you can use them exactly like the versions you're already using; you don't have to put it on a USB key or anything.) I'm looking forward to see a portable windows version of LilyPond too... I don't know if the PATH can be modified on the fly. I know something that could potentially fix the problem, but I'm a little afraid to try. When I install the GTK (with LilyPond already there), it asks me if I want to rename some of the LilyPond files (I've always said no). Will LilyPond still work if I rename these files? I'm afraid not. You can try, though. Good luck :) Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: PianoStaff spacing in 2.11
Perhaps, this is related to
http://code.google.com/p/lilypond/issues/detail?id=445start=100
Try adding
\layout{
\context{
\Staff
\override VerticalAxisGroup #'minimum-Y-extent = #'(-4 . 4)
}
}
to your file and see if it improves the situation.
/Mats
Neil Puttock wrote:
Hi everybody,
A short while back, I was under the misapprehension that there was
something wrong with the spacing in piano staves when using version
2.11. Having erroneously submitted a bug report to this effect, I
found out that thanks to the new spacing engine, the fixed distance
workaround present in 2.10 was no longer necessary (hence why the
PianoStaff centred dynamics template no longer works properly).
I have been typesetting a few piano pieces, and have found that the
spacing can vary wildly, especially when adding dynamics. This is, in
my opinion, a rather unfortunate situation, and one not in keeping
with traditional engraving rules for piano music.
My question is this: Is it possible to force fixed distance between
the staves in a PianoStaff under version 2.11? I've tried various
overrides, but all they tend to do is influence the minimum spacing
and amount of system stretching.
Thanks,
Neil
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
2007/7/21, Valentin Villenave [EMAIL PROTECTED]: Looks great (I've often been looking for such a tip in the past). I'll make a patch soon. Mmm... still haven't made any patch yet :( Sorry. Since we're talking about GDP and rewriting changing-defaults.itely, I think we shouldn't forget to add your tip about the order of definitions, Trevor. (For the original mail, see http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00526.html ) Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: PianoStaff spacing in 2.11
Hi Trevor Have you tried using the alignment-offsets part of the NonMusicalPaperColumn's line-break-system-details property? Here's an example where we override the NonMusicalPaperColumn grob in the Score's context block; the result is completely fixed vertical distance throughout the score: Excellent! Thank you. It would be nice to have this set by default for PianoStaff, but I suppose that's a bit difficult since NonMusicalPaperColumn lives in the Score context. Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
On 9/11/07, Valentin Villenave [EMAIL PROTECTED] wrote: 2007/7/21, Valentin Villenave [EMAIL PROTECTED]: Looks great (I've often been looking for such a tip in the past). I'll make a patch soon. Mmm... still haven't made any patch yet :( Sorry. Since we're talking about GDP and rewriting changing-defaults.itely, I think we shouldn't forget to add your tip about the order of definitions, Trevor. (For the original mail, see http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00526.html ) Sure. If you or Graham tell me where to stick the content, I'll turn that post into real docs. (I've lost track of the halftime score on the doc discussion: in the 2.11 manual, 9.2.7 Defining new contexts talks about this stuff; under the 2.11 structure I would say that we rename 9.2.7 Defining new contexts from scratch and then create a new subsection (9.2.8) Defining new contexts from existing contexts. But do we want two sections like this in the new manual? Or are we now lumping such things together? Just let me know and I'll write accordingly.) -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: flattening the manual to two layers?
Hey Graham, hey everyone, The GDP discussion has been extremely interesting and I think I've caught up on most of the threads. But I'm not certain so feel free to tell me if this topic has already come up. Question: has anyone suggested replacing the three-layer chapter / section / section structure with a two-layer chapter / section structure? The major sections are extremely useful and have, importantly, self-evident titles; but I've never felt that grouping the major sections into basic, decorating, instrument-specific etc really buys anything ... it's always going to be quite arbitrary as to what counts as basic versus decorating versus text, IMO, so maybe best to just kill the false disctinctions. That would leave us with a 20 or 30 chapter manual, which makes perfect sense for something like a notation reference for an engraving system (again IMO). So like this: o 6 Pitches + 6.1 Normal pitches + 6.2 Accidentals + 6.3 Cautionary accidentals + 6.4 Micro tones + 6.5 Note names in other languages + 6.6 Relative octaves + 6.7 Octave check + 6.8 Rests + 6..9 Skips o 7 Affecting multiple pitches + 7.1 Clef + 7.2 Key signature + 7.3 Transpose + 7.4 Instrument transpositions + 7.5 Ottava brackets o 8 Rhythms + 8.1 Durations + 8.2 Augmentation dots + 8.3 Tuplets + 8.4 Scaling durations + 8.5 Automatic note splitting + 8.6 Aligning to cadenzas o 9 Meter + 9.1 Time signature + 9.2 Partial measures + 9.3 Unmetered music + 9.4 Polymetric notation (alternating) + 9.5 Polymetric notation (simultaneous) + 9.6 Time administration + 9.7 Proportional notation (introduction) + 9.8 Automatic beams + 9.9 Manual beams + 9.10 Feathered beams o 10 Bars + 10.1 Bar check + 10.2 Barnumber check + 10.3 Multi measure rests + 10.4 Bar lines + 10.5 Bar numbers + 10.6 Rehearsal marks etc ... -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: flattening the manual to two layers?
On 11.09.2007 (06:41), Trevor Bača wrote: Hey Graham, hey everyone, The GDP discussion has been extremely interesting and I think I've caught up on most of the threads. But I'm not certain so feel free to tell me if this topic has already come up. Question: has anyone suggested replacing the three-layer chapter / section / section structure with a two-layer chapter / section structure? The major sections are extremely useful and have, importantly, self-evident titles; but I've never felt that grouping the major sections into basic, decorating, instrument-specific etc really buys anything ... it's always going to be quite arbitrary as to what counts as basic versus decorating versus text, IMO, so maybe best to just kill the false disctinctions. That would leave us with a 20 or 30 chapter manual, which makes perfect sense for something like a notation reference for an engraving system (again IMO). I really second this, and it also seems to be perfectly in line with the overall intention of the rewrite. If all the tutorial stuff is kept separate from the manual, there is no need for that kind of arbitrary distinctions between basic and advanced etc. that Trevor mentions. Eyolf -- April 1 This is the day upon which we are reminded of what we are on the other three hundred and sixty-four. -- Mark Twain, Pudd'nhead Wilson's Calendar ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
2007/9/11, Trevor Bača [EMAIL PROTECTED]: (I've lost track of the halftime score on the doc discussion: in the 2.11 manual, 9.2.7 Defining new contexts talks about this stuff; under the 2.11 structure I would say that we rename 9.2.7 Defining new contexts from scratch and then create a new subsection (9.2.8) Defining new contexts from existing contexts. But do we want two sections like this in the new manual? Or are we now lumping such things together? Just let me know and I'll write accordingly.) The whole thing is to be rewritten from scratch during the GDP-ization process, so I guess Graham will be glad if he's offered some help then. But this will take place in several weeks anyway. Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: PianoStaff spacing in 2.11
2007/9/11, Neil Puttock [EMAIL PROTECTED]: It would be nice to have this set by default for PianoStaff, but I suppose that's a bit difficult since NonMusicalPaperColumn lives in the Score context. No: the *real* question is: who's gonna add it to the Lilypond Snippet Repository ASAP? :) (to whoever is: the whole thing may need to be commented, since LSR is still running 2.10. Just add [needs upgrade] or something in the Subject, so I can remember to uncomment it once it's upgraded) Cheers, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: length/page-splitting of subsections
On Mon, 10 Sep 2007, Graham Percival wrote: To summarize some discussions: ... - Does anybody _like_ the current layout? If so, speak up now or forever hold your peace. :) I am _fine_ with the current layout. However, I agree that for global searching in the web browser, you need a big html page, as has already pointed out by various other people. However, if you really _cry_ for global searching, this fact may indicate that the current index is (for whatever reason) unsufficient. Regarding the current index, I wonder why the items of the command index also appear in the large index, thus making it unnecessarily long. Lack of consistency is IMHO another major problem (btw. there is a typo in the index as of .32: \displayLilyMusc iso. \displayLilyMusic). Another problem is that documentation writers often do not consider under which terms a reader of the manual may try to look up a feature; often only the most specific term is used; synonyms or categorizing terms are missing. One example (which is most likely my own fault ;-)) is ancient notation: if you are looking for ancient in alphabetical order, you will not find anything in the index. Ancient only occurs in composed terms such as rests, ancient or as part of the associated section name. At least in the printed version (i.e. without CTRL-F search available) you are lost. Similarly, you will find killCues only under k but not under cues (i.e. if you do not know the exact name, it will be hard for you to find it in the manual). Furthermore, I would like to see entries like \displayLilyMusic: Displaying LilyPond notation \displayLilyMusic: Displaying music expressions rather being structured as follows: \displayLilyMusic: Displaying LilyPond notation Displaying music expressions Given the large size of the documentation, a single person probably can not care for documentation-wide consistency of these (important!) nitpicks. Maybe a general good idea is to collect a couple of do and don't examples as guideline for documentation writers? Greetings, Juergen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: flattening the manual to two layers?
2007/9/11, Eyolf Østrem [EMAIL PROTECTED]: On 11.09.2007 (06:41), Trevor Bača wrote: Question: has anyone suggested replacing the three-layer chapter / section / section structure with a two-layer chapter / section structure? I suggested avoiding subsubsections such as in current Vocal music. Graham is reluctant to make more chapters (still can't forget about his four letters answer in a private mail :) but as more and more users ask for structural changes, he might want to explain his reluctance... I personnally have mixed feelings about this. On one hand I suspect more chapters would make the manual less visibly structured (large chapters help understand the different kinds of logics in LilyPond), on the other hand I voted myself for independant Vocal and Ancient chapters. I guess the main goal is to make life easier for everyone. Since everybody, more or less, is using lyrics, I thought Vocal music should be very visible. But the same isn't (unfortunately) true for Ancient music... there is no need for that kind of arbitrary distinctions between basic and advanced etc. that Trevor mentions. Graham's whole point is to make Basic/Advanced/etc disappear anyway. There's quite a conscensus about that. Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
How to make different horizontal spacing for each staff?
Hello! How can I make a different horizontal spacing for each staff or staff group? I need to write a modern notation piece where there is one staff with every bar with different time signature and one staff group in 3/4. All staves have a common barline at the end of every system. The rythm of the music is quite free, it is not at all necessary that the beats in different staves would be exactly at the same vertical position. Time signature changes in one staff make especially the little notes in other staves badly readable. Is there a way to have independent horizontal spacing for each staff? Thanks Vít ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: PianoStaff spacing in 2.11
On 9/11/07, Valentin Villenave [EMAIL PROTECTED] wrote: 2007/9/11, Neil Puttock [EMAIL PROTECTED]: It would be nice to have this set by default for PianoStaff, but I suppose that's a bit difficult since NonMusicalPaperColumn lives in the Score context. No: the *real* question is: who's gonna add it to the Lilypond Snippet Repository ASAP? :) OK, you've twisted my arm. ;) (to whoever is: the whole thing may need to be commented, since LSR is still running 2.10. Just add [needs upgrade] or something in the Subject, so I can remember to uncomment it once it's upgraded) Would you mind commenting http://lsr.dsi.unimi.it/LSR/Item?id=304 too? When I added it I was still using 2.10, but obviously under 2.11 tweaking spanners is quite different. Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
Valentin Villenave wrote: 2007/9/11, Adam James Wilson [EMAIL PROTECTED]: Perhaps two examples - one manually beaming non-tuplets-tuplets and one manually beaming tuplets-non-tuplets (maybe just the examples below) - could be added to the 2.11 manual under tuplets? I'd be happy to write up a little chunk of text if that would help. That this is definitely a LSR-worthy tip (I've been looking for such a tip for hours myself). Adam: thanks for your offer! Instructions are here: http://lilypond.org/web/devel/participating/documentation-adding That said, we're currently in the middle of some huge documentation work, so it might be easier to simply add it to LSR. When we examine each piece of documentation in detail, we'll also be looking at the latest LSR snippets and moving relevant ones into the main doc text. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
Trevor Bača wrote: On 9/11/07, Valentin Villenave [EMAIL PROTECTED] wrote: (For the original mail, see http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00526.html ) Sure. If you or Graham tell me where to stick the content, I'll turn that post into real docs. Thanks for the offer, but this is exactly what I don't want to be doing now... (I've lost track of the halftime score on the doc discussion: in the 2.11 manual, ... for precisely this reason. :) We *need* to settle on the overall design of the manual before we can start doing things like this. Make a note of that link, and we'll revisit it once we get to GDPizing that chapter. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Volta with text snippet needs font correcting
Hello everybody, I don't know who has sent the following snippet, but there seems to be a bug with fonts in it: http://lsr.dsi.unimi.it/LSR/Item?u=1id=317 If the author of the original snippet can correct it, it would be great; otherwise, anyone can feel free to post the correct input in this mailinglist thread. Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: PianoStaff spacing in 2.11
2007/9/11, Neil Puttock [EMAIL PROTECTED]:
Would you mind commenting
http://lsr.dsi.unimi.it/LSR/Item?id=304 too? When I added
it I was still using 2.10, but obviously under 2.11 tweaking spanners is
quite different.
I'll just mark it as unapproved for now; it works well with 2.10. If
you (or anyone) send the updated code, then I'll edit it and comment
it until the LSR upgrades.
\relative c'' {
\override TrillSpanner #'edge-text =
#(cons (markup #:line (#:halign -0.5 #:musicglyph scripts.trill
#:teeny #:raise 0.65 #:sharp)) )
b1\startTrillSpan b\stopTrillSpan
\override TrillSpanner #'edge-text =
#(cons (markup #:line (#:halign -0.5 #:musicglyph scripts.trill
#:teeny #:raise 0.5 #:flat)) )
c\startTrillSpan c\stopTrillSpan
}
Thanks
Valentin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
2007/9/11, Graham Percival [EMAIL PROTECTED]: We *need* to settle on the overall design of the manual before we can start doing things like this. Hence the last sentence in my previous mail :) 2007/9/11, Valentin Villenave [EMAIL PROTECTED]: But this will take place in several weeks anyway. Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
On 9/11/07, Valentin Villenave [EMAIL PROTECTED] wrote: 2007/9/11, Adam James Wilson [EMAIL PROTECTED]: Perhaps two examples - one manually beaming non-tuplets-tuplets and one manually beaming tuplets-non-tuplets (maybe just the examples below) - could be added to the 2.11 manual under tuplets? I'd be happy to write up a little chunk of text if that would help. That this is definitely a LSR-worthy tip (I've been looking for such a tip for hours myself). To add a dissenting voice, I don't think this is LSR-worthy, in my humble opinion. Surely it's clear from the postfix-style syntax for manual beaming that the right square bracket should directly follow the note which is to be at the end of the requested beaming, i.e. inside the tuplet section? Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to make different horizontal spacing for each staff?
Have you read the section on Polymetric notation? You may also want to play with the techniques described in Scaling durations, for example. /Mats Vít Reichel wrote: Hello! How can I make a different horizontal spacing for each staff or staff group? I need to write a modern notation piece where there is one staff with every bar with different time signature and one staff group in 3/4. All staves have a common barline at the end of every system. The rythm of the music is quite free, it is not at all necessary that the beats in different staves would be exactly at the same vertical position. Time signature changes in one staff make especially the little notes in other staves badly readable. Is there a way to have independent horizontal spacing for each staff? Thanks Vít ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
Neil Puttock wrote: To add a dissenting voice, I don't think this is LSR-worthy, in my humble opinion. Surely it's clear from the postfix-style syntax for manual beaming that the right square bracket should directly follow the note which is to be at the end of the requested beaming, i.e. inside the tuplet section? I agree that it's clear if you are clear about the syntax. However, since there is no clear syntax definition in the documentation today, the tip is probably LSR-worthy. The problem is that users who experience closely related problems will not find this specific snippet and it's impossible to include examples of all such situations since they are too many and too hard to forsee. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
Am Dienstag, 11. September 2007 schrieb Neil Puttock: On 9/11/07, Valentin Villenave [EMAIL PROTECTED] wrote: 2007/9/11, Adam James Wilson [EMAIL PROTECTED]: Perhaps two examples - one manually beaming non-tuplets-tuplets and one manually beaming tuplets-non-tuplets (maybe just the examples below) - could be added to the 2.11 manual under tuplets? I'd be happy to write up a little chunk of text if that would help. That this is definitely a LSR-worthy tip (I've been looking for such a tip for hours myself). To add a dissenting voice, I don't think this is LSR-worthy, in my humble opinion. Surely it's clear from the postfix-style syntax for manual beaming that the right square bracket should directly follow the note which is to be at the end of the requested beaming, i.e. inside the tuplet section? After you found out, it makes sense (because the bracket is not a bracket in the sense that it encloses something, but rather an attribute to the note). But if you are used to writing code, interleaving brackets and braces seems completely counter-intuitive (in particular since lilypond is very picky about slurs when you work with \\ ). I ran into this very problem a while back and it took me some time to figure out that I can interleave the brackets. Once you have found out how it works, it might seem like a no-brainer, but if you have not yet, then such a snippet is quite useful Cheers, Reinhold -- -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
On 9/11/07, Reinhold Kainhofer [EMAIL PROTECTED] wrote: After you found out, it makes sense (because the bracket is not a bracket in the sense that it encloses something, but rather an attribute to the note). But if you are used to writing code, interleaving brackets and braces seems completely counter-intuitive (in particular since lilypond is very picky about slurs when you work with \\ ). I ran into this very problem a while back and it took me some time to figure out that I can interleave the brackets. Well, I'm no programmer, so that could explain why I've never given it a second thought. Once you have found out how it works, it might seem like a no-brainer, but if you have not yet, then such a snippet is quite useful The problem is, as Mats says, it's not specific to beaming; it applies equally to things like slurs and ties. If a snippet is to be submitted to LSR, it needs to be more generalized. Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GTK and LilyPond
Valentin Villenave wrote: 2007/9/11, Mark Dewey [EMAIL PROTECTED]: Anyway, whenever I install LilyPond, GIMP doesn't work anymore because of something to do with this. I don't know which GTK applications you're using, but the opposite could be done easily, i.e. standard LilyPond installation, *but* instead of using a GTK installation, you can use a portable version of every other GTK application you need: http://portableapps.com/apps/internet/pidgin_portable http://portableapps.com/apps/graphics_pictures/gimp_portable etc... I was mostly needing it for GIMP, so this information should help out a lot. Once in a while, though, I come across something else I need it for, but I don't remember what off hand (whatever the case, it's not as important as GIMP, at the moment). I've noticed that the computer freezing thing hasn't repeated (maybe it was a one-time thing)—though I'm sure installing another version of LilyPond will still do the same thing (if I don't install the bundled GIMP/GTK). Thanks! - Mark ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GTK and LilyPond
This is weird! I have had GIMP and LilyPond installed on the same machine (Win XP) and have kept updating LilyPond every now and then. Still, GIMP works without any problems. /Mats Mark Dewey wrote: Valentin Villenave wrote: 2007/9/11, Mark Dewey [EMAIL PROTECTED]: Anyway, whenever I install LilyPond, GIMP doesn't work anymore because of something to do with this. I don't know which GTK applications you're using, but the opposite could be done easily, i.e. standard LilyPond installation, *but* instead of using a GTK installation, you can use a portable version of every other GTK application you need: http://portableapps.com/apps/internet/pidgin_portable http://portableapps.com/apps/graphics_pictures/gimp_portable etc... I was mostly needing it for GIMP, so this information should help out a lot. Once in a while, though, I come across something else I need it for, but I don't remember what off hand (whatever the case, it's not as important as GIMP, at the moment). I've noticed that the computer freezing thing hasn't repeated (maybe it was a one-time thing)—though I'm sure installing another version of LilyPond will still do the same thing (if I don't install the bundled GIMP/GTK). Thanks! - Mark ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
re: regression test
Oops... In that last email, I meant #'staff-position (from staff- symbol-referencer-interface). =\ Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
Valentin Villenave wrote:
2007/9/11, Neil Puttock [EMAIL PROTECTED]:
Well, I'm no programmer, so that could explain why I've never given it a
second thought.
Still; you're used to write
(inside parentheses), and not
outside( parentheses)
aren't you? :)
The problem is, as Mats says, it's not specific to beaming; it applies
equally to things like slurs and ties. If a snippet is to be submitted to
LSR, it needs to be more generalized.
I tried to make it general in the following snippet
http://lsr.dsi.unimi.it/LSR/Item?u=1id=321
As always, please correct me if you notice English aberrations...
Fine, but I'm sure we will see the same basic question coming
back in other situations, where the curly braces instead belong
to a \repeat{...} or \relative{...} or \grace{...} or ... and sooner or
later we will exhaust both snippet writers as well as the users
trying to search the growing amount of snippets.
The solution is to try to make the general principles as clear as
possible in the manual, so you don't have to include a specific
example of every single special case in the LSR.
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: length/page-splitting of subsections
Am 2007-09-11 um 01:13 schrieb John Mandereau: Such symlinks already exist, but were only known by the webmasters and the translators. Have a look at this updated page to know about those permanent links: http://lilypond.org/web/documentation (Wait for one hour or two for the automatic regeneration of lilypond.org from the web sources.) Thank you! Greetlings from Lake Constance --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net http://angerweit.tikon.ch/lieder/ https://www.cacert.org (I'm an assurer) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
Mats Bengtsson wrote:
The problem is, as Mats says, it's not specific to beaming; it applies
equally to things like slurs and ties. If a snippet is to be
submitted to
LSR, it needs to be more generalized.
Fine, but I'm sure we will see the same basic question coming
back in other situations, where the curly braces instead belong
to a \repeat{...} or \relative{...} or \grace{...} or ... and sooner or
later we will exhaust both snippet writers as well as the users
trying to search the growing amount of snippets.
The solution is to try to make the general principles as clear as
possible in the manual, so you don't have to include a specific
example of every single special case in the LSR.
I've added this as a general issue to address when working on the
learning manual. Probably in about three months.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: in a perfect world, nothing but RTFM
I should clarify one point: in only the past three years, I've seen a lot of lilypond's documentation become out of date. That makes me look for long-term solutions for the docs. I really think of this like software engineering: planning and designing a computer program may seem like a waste to beginning programmers, but experienced programmers know that it really is worth it to spend more than 50% of your time on design, instead of programming. * actual percentage completely made up. Don't quote some software engineering textbook at me. :P In a perfect world, the only discussions on -user would be this: 1) Q: how do I foo? 2) ??? 3) A: RTFM section x.y.z. 4) Profit. (Obviously step 3 would be phased nicer than RTFM.) The missing step 2 is that we work on the docs. This isn't quite practical -- we only upload the docs every one or two weeks, and we have a limited amount of time/effort/interest in maintaining the docs. But I honestly think that if everybody stopped answering questions on -user, after a year we would have *amazing* documentation. The first few months would suck, of course. LSR makes this ideal much more practical. Anybody can upload an example, and answer a question on -user with a link to that example. The doc team can then mark certain examples to be included in our Snippets section, and every so often we can move really great snippets into the actual manual. At the moment, there might be some useful snippets in the regtests that aren't in LSR. As I've said before, that's considered a bug. I honestly think that there are fewer than half a dozen such snippets -- I've looked through the regtests for good snippets, and Valentin has done the same. If you find any, please add them to LSR. (NB: regtests which can't be shown in LSR because they use new features are in input/new/. This should be resolved soon) That's why I'm so adamant that the regtests should not be on the main doc page. Short-term pain (for a small number of advanced users, who should know bloody well how to add stuff to LSR, anyway) for long-term gain (having a single place to look for short examples). Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: flattening the manual to two layers?
Valentin Villenave wrote: I suggested avoiding subsubsections such as in current Vocal music. Graham is reluctant to make more chapters (still can't forget about his four letters answer in a private mail :) Ok, come on, it was hilarious! But we really need to explain this. John and Valentin were dithering about Vocal music: should we leave it in instrument-specific, or make it a new chapter... but it's too short to be a chapter by itself... what to do, what to do...? My response: hmm, yeah... vocal music is tricky. If only we had a dedicated chapter for putting words on the page... especially if we had a new, dedicated chapter, that was much shorter than the other chapters... we could give that chapter a nice short name, like word, or maybe something else with four letters... Poor Valentin thought I was swearing at him*. I, of course, was referring to the new chapter Text. * in English, most swearwords have four letters; the phrase four-letter words generally** refers to swearwords. ** one of my conductors make jokes about this: no, no! You're playing loud, and `loud' is a four-letter word. Think `heroic' or `strong' instead! No four-letter words in this orchestra! Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GTK and LilyPond
2007/9/11, Mats Bengtsson [EMAIL PROTECTED]: This is weird! I have had GIMP and LilyPond installed on the same machine (Win XP) and have kept updating LilyPond every now and then. Still, GIMP works without any problems. There are many different GIMP installation packs for windows. I remember having used one several years ago, which installed GTK in a different folder, and changed the whole system variables in order to use it :( This might be why Mark has encountered such issues (maybe a conflict with pango or something?) Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: to all offers of help
To everybody who offered to help with trivial and easy stuff, thanks! Sorry I haven't responded earlier, but we're still planning stuff that needs to be done before I have tasks for you. Unfortunately we need to do all the rearranging at once, otherwise the translations go crazy. Blame the translation project. ;) Rest assured that I _will_ have work for you, but probably not starting until this weekend or early next week. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: summary and directions, 11 Sep
If you're somewhat interested in GDP, but don't want to follow the 50-email monster threads, simply read any email by me that starts a subject. Not because I think my opinion is the only one that matters :). Just because I'll sum up the important points, and attempt to direct future discussions, in emails like this. ALMOST-CERTAIN (barring massive opposition, this will happen) ** split the Learning Manual (chapters 2-5) into a separate manual, just like Program Usage. cons: no shared index with Notation Reference. Benefits: no shared index with Notation Reference. :)besides, chapters 2-5 have hardly any index entries, anyway. I don't know what to do about chapter 1 (general intro, background). The about this manual will obviously stay in some form or other. Omit that section from the discussion for now. Opinions about the rest of chapter 1 are desired, though. ** combine multiple subsections into single subsections. Something like an average of 3 subsections - 1. Assuming there isn't significant opposition in the next 18 hours, I'll take a stab at creating the new merged subsections. ** Abandon basic/advanced/instrument/decorating/cakes division of notation reference. See below as to how we do this, though. NEEDS DISCUSSION ** should the combined index include entires in the command index ? We could easily separate the concept index from the combined index. Would that help or hurt? ( assuming that we added many more index entries; don't bother commenting that we don't have enough right now ) ** combined subsections: print names of old subsections in the manual? For example, suppose we make a printing repeats section that includes Repeat types, Repeat syntax, Repeats and MIDI, and Manual repeat commands. Do you want to only see Printing repeats in the table of contents, or do you want to see x.y Printing repeats Repeat types Repeat syntax ... (without any x.y.z numbers) ** Abandon decorating/cakes method of dividing the notation reference. There's sufficient support for this, but I have some remaining concerns: Pitch and Rhythm are more connected than Pitch and Spacing or Pitch and Changing defaults. Now, we could indicate this purely by the proximity of chapters -- Pitch is chapter 1, Spacing is chapter 27. Or, we could have a single chapter for all Notation. 1. Notation 1.1 Pitches 1.2 Rhythms ... 2. Text (arguably as 1.25 inside Notation) 3. Input and output 4. Spacing 5. Changing defaults 6. Interfaces for programmers (exact order of the chapters to be determined) I'd rather have this kind of setup. Yes, chapter 1 will have 25 sections (or whatever), but IMO something like Repeats just shouldn't be at the same level as Changing defaults. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: flattening the manual to two layers?
2007/9/11, Graham Percival [EMAIL PROTECTED]: Ok, come on, it was hilarious! But we really need to explain this. Yes, that made me laugh quite a while indeed... Poor Valentin thought I was swearing at him*. I, of course, was referring to the new chapter Text. The truth is, I had no idea you were actually refering to something! Now, don't tell me you were trying to avoid the ambiguity... :) However, the GDP is creating quite a storm on both -user and -devel; I try to keep up but we will soon need some strong points. For instance, you could open a new thread and yell in the Subject field No new chapter will be allowed under 5000 lines of texinfo code!!! (come on, you know how to yell, don't you :) Because in case you didn't notice, everybody seems to have suddenly awaken; lots of users are asking for either longer subsections or shorter chapters (which is indeed kind of a paradox). Every one has good points, strong arguments no matter what's his point of view... Frankly, I don't know if you realize what you've started ;-) Cheers, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GTK and LilyPond
That is pretty weird. Does anyone else here have Windows 2000 who would be willing to test this (to see if it's just me)? Windows 2000 and XP should be essentially the same with this, though . . . hence the weirdness on my part. I'll have to try it on another computer if I ever get the chance. - Mark Mats Bengtsson wrote: This is weird! I have had GIMP and LilyPond installed on the same machine (Win XP) and have kept updating LilyPond every now and then. Still, GIMP works without any problems. /Mats Mark Dewey wrote: Valentin Villenave wrote: 2007/9/11, Mark Dewey [EMAIL PROTECTED]: Anyway, whenever I install LilyPond, GIMP doesn't work anymore because of something to do with this. I don't know which GTK applications you're using, but the opposite could be done easily, i.e. standard LilyPond installation, *but* instead of using a GTK installation, you can use a portable version of every other GTK application you need: http://portableapps.com/apps/internet/pidgin_portable http://portableapps.com/apps/graphics_pictures/gimp_portable etc... I was mostly needing it for GIMP, so this information should help out a lot. Once in a while, though, I come across something else I need it for, but I don't remember what off hand (whatever the case, it's not as important as GIMP, at the moment). I've noticed that the computer freezing thing hasn't repeated (maybe it was a one-time thing)—though I'm sure installing another version of LilyPond will still do the same thing (if I don't install the bundled GIMP/GTK). Thanks! - Mark ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to beam non-tuplets with tuplets?
Hi all, Thanks everyone for being such active participants in this community - as a new user of Lilypond I'm finding it a great experience, both as a tool in and of itself and as an interaction between programmers/users/documenters/etc. I'm just looking at this thread for the first time after sending my initial question; thanks Valentin for adding the tip to LSR. I didn't mean to cause a big debate . . . but at the risk of extending the debate, here are my thoughts (as a relatively new user to Lilypond): 1) Had the manual contained a general explanation of the syntax I discovered by trial and error, I agree I'm sure I wouldn't have had to pose my question . . . 2) . . . however, I don't see anything wrong with adding a snippet to the LSR database in the meantime while the manual is being re-written; practically speaking, it would have shaved off an hour or so of searching and questioning for me. Valentin's example very clearly lays out a number of contexts in which the same syntax applies, and thus serves as a useful way to surmise syntax until the manual is updated. 3) I believe Graham mentioned that in the absence of a generalized explanation of syntax, people who program tend to base their intuitions on coding conventions; as a Common Lisp hacker, I'm used to interleaved (as opposed to imbedded) parens being a big no-no, so of course I defaulted to encapsulating the entire \times block within brackets. Best regards, Adam On 9/11/07, Mats Bengtsson [EMAIL PROTECTED] wrote: Neil Puttock wrote: To add a dissenting voice, I don't think this is LSR-worthy, in my humble opinion. Surely it's clear from the postfix-style syntax for manual beaming that the right square bracket should directly follow the note which is to be at the end of the requested beaming, i.e. inside the tuplet section? I agree that it's clear if you are clear about the syntax. However, since there is no clear syntax definition in the documentation today, the tip is probably LSR-worthy. The problem is that users who experience closely related problems will not find this specific snippet and it's impossible to include examples of all such situations since they are too many and too hard to forsee. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: summary and directions, 11 Sep
On 9/11/07, Graham Percival [EMAIL PROTECTED] wrote: If you're somewhat interested in GDP, but don't want to follow the 50-email monster threads, simply read any email by me that starts a subject. Not because I think my opinion is the only one that matters :). Just because I'll sum up the important points, and attempt to direct future discussions, in emails like this. ALMOST-CERTAIN (barring massive opposition, this will happen) ** split the Learning Manual (chapters 2-5) into a separate manual, just like Program Usage. Strongly agree. cons: no shared index with Notation Reference. Benefits: no shared index with Notation Reference. :)besides, chapters 2-5 have hardly any index entries, anyway. I don't know what to do about chapter 1 (general intro, background). The about this manual will obviously stay in some form or other. Omit that section from the discussion for now. Opinions about the rest of chapter 1 are desired, though. ** combine multiple subsections into single subsections. Something like an average of 3 subsections - 1. Strongly agree. Assuming there isn't significant opposition in the next 18 hours, I'll take a stab at creating the new merged subsections. ** Abandon basic/advanced/instrument/decorating/cakes division of notation reference. See below as to how we do this, though. Strongly agree. More comments below. NEEDS DISCUSSION ** should the combined index include entires in the command index ? We could easily separate the concept index from the combined index. Would that help or hurt? I vote for a single index. ( assuming that we added many more index entries; don't bother commenting that we don't have enough right now ) ** combined subsections: print names of old subsections in the manual? For example, suppose we make a printing repeats section that includes Repeat types, Repeat syntax, Repeats and MIDI, and Manual repeat commands. Do you want to only see Printing repeats in the table of contents, or do you want to see x.y Printing repeats Repeat types Repeat syntax ... (without any x.y.z numbers) I vote for the more verbose form of the TOC. ** Abandon decorating/cakes method of dividing the notation reference. There's sufficient support for this, but I have some remaining concerns: Pitch and Rhythm are more connected than Pitch and Spacing or Pitch and Changing defaults. Now, we could indicate this purely by the proximity of chapters -- Pitch is chapter 1, Spacing is chapter 27. Or, we could have a single chapter for all Notation. 1. Notation 1.1 Pitches 1.2 Rhythms ... 2. Text (arguably as 1.25 inside Notation) 3. Input and output 4. Spacing 5. Changing defaults 6. Interfaces for programmers (exact order of the chapters to be determined) I'd rather have this kind of setup. Yes, chapter 1 will have 25 sections (or whatever), but IMO something like Repeats just shouldn't be at the same level as Changing defaults. Oooh. You know what's emerging as a really nice pattern? The 24 (or so) sections in Notation taken together with Text looks like it might make an almost perfect Notation Reference. So would it be insanely crazy to bind (metaphorically speaking) those 25 chapters together into a single manual, cut everything else out, and call that our Notation Reference? It sounds like it would be really beautiful. So: Notation Reference 1 Pitches 2 Rhythms 25 Text That'd be very very cool imo. That then leaves the question of what to do with the other stuff. What about this? * Spacing: recast as a separate manual called Page Layout * Input and output: move to Program Usage * Changing defaults: move to Program Reference * Interfaces for programmers: move to Program Reference That would then leave the following separate books: * Learning Manual (4 or 5 chapters) * Notation Reference (25 chapters) * Page Layout (handful of chapters) * Program Usage (6 chapters) * Program Reference (15 chapters) Probably the radical idea here is elevating spacing to stauts of its own manual. But I think it makes sense -- seems to me that I'm either hunting notation-related grob settings xor figuring out how to move staves and systems apart, but not both at the same time. The coolest thing here is the possibility of a solid, 25-chapter NR. That's slick. -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
distance between lines in custom markup
Hi everyone, in the markup below, two lines of text will be printed in a column so, one on top of the other. How can I decrease/increase the vspace between them? Thanks all Adam Good % custommark = #(define-music-function (parser location marktext) (string?) (make-music 'TextScriptEvent 'direction 1 'text (markup #:column (#:line (#:small #:italic Some Text) #:small #:italic #:line (marktext) % ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GIMP, GTK, And Lilypond on Windows
Mark wrote: That is pretty weird. Does anyone else here have Windows 2000 who would be willing to test this (to see if it's just me)? Windows 2000 and XP should be essentially the same with this, though . . . hence the weirdness on my part. I'll have to try it on another computer if I ever get the chance. - Mark Mats Bengtsson wrote: This is weird! I have had GIMP and LilyPond installed on the same machine (Win XP) and have kept updating LilyPond every now and then. Still, GIMP works without any problems. /Mats Mark Dewey wrote: Valentin Villenave wrote: 2007/9/11, Mark Dewey [EMAIL PROTECTED]: Anyway, whenever I install LilyPond, GIMP doesn't work anymore because of something to do with this. I don't know which GTK applications you're using, but the opposite could be done easily, i.e. standard LilyPond installation, *but* instead of using a GTK installation, you can use a portable version of every other GTK application you need: http://portableapps.com/apps/internet/pidgin_portable http://portableapps.com/apps/graphics_pictures/gimp_portable etc... I was mostly needing it for GIMP, so this information should help out a lot. Once in a while, though, I come across something else I need it for, but I don't remember what off hand (whatever the case, it's not as important as GIMP, at the moment). I've noticed that the computer freezing thing hasn't repeated (maybe it was a one-time thing)â??though I'm sure installing another version of LilyPond will still do the same thing (if I don't install the bundled GIMP/GTK). Thanks! - Mark I run Lilypond (2.11.32), GIMP, and Inkscape (all using GTK) on my Win XP notebook and have no problems - must be a Win2k thing or some other issue. As an aside, I'm installing LaTeX now after reading an article comparing Word, OO.o Writer and LaTeX. I figure if I can use Lilypond, I can use LaTeX too! Seems like LaTeX and Lilypond share similar philosophies/aesthetics. We'll see how I get along. Tim___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: distance between lines in custom markup
Hi Adam, On 9/12/07, Adam Good [EMAIL PROTECTED] wrote: Hi everyone, in the markup below, two lines of text will be printed in a column so, one on top of the other. How can I decrease/increase the vspace between them? Have a look at text-interface in the Graphical Object Interfaces section of the program reference. Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: summary and directions, 11 Sep
Trevor Bača wrote: That then leaves the question of what to do with the other stuff. What about this? * Spacing: recast as a separate manual called Page Layout * Input and output: move to Program Usage * Changing defaults: move to Program Reference * Interfaces for programmers: move to Program Reference Nu-huh, Program Reference is where angels fear to tread, remember. :P That would then leave the following separate books: (5 books) I think that's getting too fragmented. ... My initial reaction was no way; we want to make tweaking more friendly, not less. But I had forgotten about the Learning Manual -- that clearly shows the beginning of tweaks, and (of course) more work is planned. Hmmm... *IF* it were easy to move Changing and Interfaces into the program reference, I could almost buy that. That's a pretty big if, though. If we renamed the Program Usage book, we _might_ be able to fit Spacing and Input in there. I'm not wild about it, though. But I definitely don't agree with making a separate book for Page Layout. ... ok, what about everybody else? Think about it for a few minutes before responding: my initial reaction was WTF is Trevor smoking, but I'm starting to think he wasn't crazy. Please remember the following: - HTML links between documents is cheap and easy. - introductions belong in the Learning manual. If you haven't skimmed through chapter 5, please do so. I'm planning on a least doubling the material in the LM, so users will have a good idea of how things work by the time they finish it. An extensive how to read the other books section will be included at the end of the LM. - we officially have no sympathy for users who haven't read the LM. :-) For the record, I'm still opposed to this idea, but it's now a weak reject. I could be convinced otherwise. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
