Re: \times -> \tuplet (was Re: Issue 566 in lilypond: showStaffSwitch -> \staffSwitchOn)
John Mandereau wrote: There has already been a *huge* thread on the -user list about this, and the conclusion was that the only realistic change we could do was renaming \times to \tuplet, and nothing else; the point of my remark in the bug tracker was to ask developers' opinion about actually doing this, and not about reopening the discussion -- unless you have new ideas, of course. I am still very much opposed to this as a mandatory change. Aliasing times to tuplet would be great. But I've spent a long time with the \times syntax and have never had any problem confusing it with \time. \tuplet is longer to type and falls much more strangely on the keyboard than does \times. Times is mathematically precise and describes exactly what is happening when the keyword is applied. If there is such an overwhelming problem with the confusion (and I still have trouble believing that to be the case), then an alias should be created, but we should not remove the \times keyword. Cheers, Bryan... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website Redesign
Han-Wen Nienhuys wrote: FWIW, I like designs to - use as little rules as possble - be scalable (this one introduces scrollbars at 800x600) - use real tabs I think mozilla.org is pretty much what we'd want. Unfortunately, we'll also need work on the infrastructure side to make this work. IMHO, a better start would be to clean up the current script so we can generate the 'old-school' website using CSS completely, and then do a redesign based on CSS. Greetings, I've taken a recent snapshot of the web site and put up a version at http://www.purplefrogpress.com/lilypond/ It duplicates the current web site, using standards to the best of my ability. Before I start figuring out the python that's generating the pages, I thought I'd put out a request for comments. The css is here: http://www.purplefrogpress.com/lilypond/reset.css http://www.purplefrogpress.com/lilypond/main.css Any comments and critiques are appreciated. Cheers, Bryan... ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website Redesign
Kyle N. Leitch wrote: I’ve come up with a simple (and developing) idea for a new design at my site, www.lws.cjb.cc/Lilypond <http://www.lws.cjb.cc/Lilypond>. Regardless of whether or not the new design will be used, I would greatly appreciate your feedback. Greetings from a web professional, It's a nice first step into a redesign. The concept is fairly nice and shows quite a bit of thought. 1) I recommend making the "Home" "Introduction" etc. links plain white. It's hard to read the special effect (and it requires images which increases load time, unnecessarily in this case). 2) There's a little too much space in a number of places. Between the header and the navigation, for instance. That seems a lot of extraneous space. 3) I think that perhaps you're using too many different colors, especially in the uses of headers. 4) The markup is very "old school." Your design could easily be accomplished with fully compliant (X)HTML+CSS and be leaner and load faster as a result. It would also be more appropriately elegant for such an elegant program. (Granted the originally is equally "old school") If there's any interest in this, I could take a look later this week and bring your design into a standards compliant format and then post for comments. (If there's any question of my qualifications to take incredibly table-heavy code and translate it into (X)HTML+CSS, please see http://www.bgsu.edu for the ugly table version and http://www.bgsu.edu/music/ for my redesign with one table [that's largely unnecessary, but for a few pages. I'm working on getting the table out of there entirely, since there's no tabular data.]). Cheers, Bryan... --- Bryan Stanbridge Purple Frog Productions ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača wrote: I dunno. I don't wanna type more stuff (explicit \score and \book and whatever) all the time, but I'm pretty convinced that both file structure and score structure will remain confusing for new and even experienced users right up until the point that we do make such a requirement. What about adding some sort of switch? An advanced option, so to speak. Much like I include #(ly:set-option 'point-and-click #f) at the top of every score, since I don't need point and click, maybe we could create a #(ly:set-option 'strict-structure #f) for advanced users. This would allow for requiring strict file structure until you feel comfortable enough to not need it. We would probably have to allow it as a command line option as well, otherwise all the doc examples, etc., would need the switch and that could be cumbersome. Just thinking out loud, here. I haven't delved into the code that allows the structure to be so fluid, so I'm not sure how much work this would be to implement. Cheers, Bryan... --- Bryan Stanbridge[EMAIL PROTECTED] Purple Frog Press www.purplefrogpress.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
David Rogers wrote: The correct answer is (I believe) exactly as you proposed earlier. Talking about Lilypond's internal logic is IMHO counterproductive. In fact, internally, I suspect Lilypond should stay the same - it just needs to allow the user to use it effectively by making (or even just *allowing*) the logical separation between paper, headers, and music, which you already outlined. It would be great if we could also leave the current mechanism in place if we do such a change. The system made sense to me from the beginning and I'd prefer to think in terms of scope (I have a strong programming background). I don't oppose a division on its merits, but it would be nice if the format would stay the same. Cheers, Bryan... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Possible Bug in v2.9.8 LaissezVibrerTie for single notes
Greetings all,
v2.9.8-1 on Windows, native.
It seems that LaissezVibrerTie #'direction doesn't affect laissez vibrer ties on
single notes. I haven't tested the override for chords as I'm specifically
interested only in the semi-ties on single notes.
If semi-ties worked like full ties on single notes (in terms of direction), then
I wouldn't need to override these in the first place, so I suspect that may be
another aspect of the bug. Regardless of what I do, or where the note is on the
staff, a laissez vibrer (semi-tie) is always down on the note.
Here's my test code.
\version "2.9.8"
\score {
\new Staff {
d''4\laissezVibrer
\override LaissezVibrerTie #'direction = #UP
d''4\laissezVibrer
\override LaissezVibrerTie #'direction = #1
d''4\laissezVibrer
r4
}
}
Cheers,
Bryan...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
\laissezVibrer not working with single notes
Greetings all,
I can't remember if bug reports for development versions should also be
posted in bugs- or just devel-, so here's my post here and if I need to
post to both (or just bugs) in the future, please let me know.
In my experience, \laissezVibrer does not work in v2.7.34 or
2.7.35/WindowsXPSP2 on single notes. It works just fine with chords.
Here's my test.ly example:
\version "2.7.35"
\score {
% \laissezVibrer
%% the above line works just fine, the one below crashes every time
g'\laissezVibrer
}
Lilypond always crashes after the display "Calculating line breaks" in
the log file. I tried dragging onto the lilypond icon, double-clicking
the test.ly file, and running it verbosely from the command line.
I can capture the report it wants to send to Microsoft to send to a
developer off-list, if that will help.
Here's the output of lilypond --verbose from the command line.
GNU LilyPond 2.7.35
warning: Relocation: from
PATH=C:\LilyPond\usr\bin;C:\WINDOWS\system32;C:\WINDOW
S;C:\WINDOWS\System32\Wbem;C:\Program Files\American
Express\BLUE;C:\Program Fil
es\ATI Technologies\ATI Control Panel;C:\Program Files\Common
Files\GTK\2.0\bin;
C:\;C:\WINDOWS;C:\WINDOWS\SYSTEM32;C:\WINDOWS\SYSTEM32\WBEM;C:\ARCHIVER
argv0=lilypond
warning: Relocation: compile prefix=/usr/share/lilypond/2.7.35, new
prefix=C:/Li
lyPond/usr
PATH=C:/LilyPond/usr/bin
warning: Relocation: framework_prefix=C:/LilyPond/usr/bin/..
DYLD_LIBRARY_PATH=C:/LilyPond/usr/bin/../lib
GS_FONTPATH=C:\WINDOWS/fonts
warning: no such directory:
C:/LilyPond/usr/bin/../share/ghostscript/8.50/fonts
for GS_FONTPATH
warning: no such directory:
C:/LilyPond/usr/bin/../share/ghostscript/8.50/Resour
ce for GS_LIB
GS_LIB=C:/LilyPond/usr/bin/../share/ghostscript/8.50/lib
warning: no such directory: C:/LilyPond/usr/bin/../share/gs/fonts for
GS_FONTPAT
H
warning: no such directory: C:/LilyPond/usr/bin/../share/gs/Resource for
GS_LIB
warning: no such directory: C:/LilyPond/usr/bin/../share/gs/lib for GS_LIB
GUILE_LOAD_PATH=C:/LilyPond/usr/bin/../share/guile/1.7
PATH=C:/LilyPond/usr/bin/../bin
LILYPOND_DATADIR="/usr/share/lilypond/2.7.35"
LOCALEDIR="/usr/share/locale"
Effective prefix: "C:/LilyPond/usr/share/lilypond//2.7.35"
FONTCONFIG_FILE="C:/LilyPond/usr/bin/../etc/fonts/fonts.conf"
FONTCONFIG_PATH="C:/LilyPond/usr/bin/../etc/fonts"
GS_FONTPATH="C:\WINDOWS/fonts"
GS_LIB="C:/LilyPond/usr/bin/../share/ghostscript/8.50/lib"
GUILE_LOAD_PATH="C:/LilyPond/usr/bin/../share/guile/1.7"
PANGO_RC_FILE="C:/LilyPond/usr/bin/../etc/pango/pangorc"
PATH="C:/LilyPond/usr/bin/../bin;C:/LilyPond/usr/bin;C:\LilyPond\usr\bin;C:\WIND
OWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\American Expre
ss\BLUE;C:\Program Files\ATI Technologies\ATI Control Panel;C:\Program
Files\Com
mon
Files\GTK\2.0\bin;C:\;C:\WINDOWS;C:\WINDOWS\SYSTEM32;C:\WINDOWS\SYSTEM32\WBE
M;C:\ARCHIVER"
[C:/LilyPond/usr/share/lilypond//2.7.35/scm/lily.scm]
[C:/LilyPond/usr/share/lilypond//2.7.35/scm/lily-library.scm][C:/LilyPond/usr/sh
are/lilypond//2.7.35/scm/file-cache.scm][C:/LilyPond/usr/share/lilypond//2.7.35/
scm/define-music-types.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/output-li
b.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/c++.scm][C:/LilyPond/usr/share
/lilypond//2.7.35/scm/chord-ignatzek-names.scm][C:/LilyPond/usr/share/lilypond//
2.7.35/scm/chord-entry.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/chord-gen
eric-names.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/stencil.scm][C:/LilyP
ond/usr/share/lilypond//2.7.35/scm/markup.scm][C:/LilyPond/usr/share/lilypond//2
.7.35/scm/music-functions.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/part-c
ombiner.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/autochange.scm][C:/LilyP
ond/usr/share/lilypond//2.7.35/scm/define-music-properties.scm][C:/LilyPond/usr/
share/lilypond//2.7.35/scm/auto-beam.scm][C:/LilyPond/usr/share/lilypond//2.7.35
/scm/chord-name.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/parser-ly-from-s
cheme.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/define-context-properties.
scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/translation-functions.scm][C:/Li
lyPond/usr/share/lilypond//2.7.35/scm/script.scm][C:/LilyPond/usr/share/lilypond
//2.7.35/scm/midi.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/layout-beam.sc
m][C:/LilyPond/usr/share/lilypond//2.7.35/scm/parser-clef.scm][C:/LilyPond/usr/s
hare/lilypond//2.7.35/scm/layout-slur.scm][C:/LilyPond/usr/share/lilypond//2.7.3
5/scm/font.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/encoding.scm][C:/Lily
Pond/usr/share/lilypond//2.7.35/scm/fret-diagrams.scm][C:/LilyPond/usr/share/lil
ypond//2.7.35/scm/define-markup-commands.scm][C:/LilyPond/usr/share/lilypond//2.
7.35/scm/define-grob-properties.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/
define-grobs.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/define-grob-interfa
ces.scm][C:/LilyPond/usr/share/lilypond//2.7.35/scm/def
Re: DOS-based Windows users, please test
>[EMAIL PROTECTED] wrote: Ok. Going back to our previous attempt. I have attached a batch file which corrects the GS_LIB problem and successfully creates a PDF on MS Windows 98SE. Paul set lily=c:\progra~1\lilypond\usr set GS_LIB=%lily%\share\gs\lib set GS_FONTPATH=c:\windows\fonts %lily%\bin\gs -dCompatibilityLevel#1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE#pdfwrite -sOutputFile#"simple.pdf" -c .setpdfwrite -f ."simple.ps" Don't forget that not all windows installations will put windows in c:\windows. Someone may have installed it to WinME, Win98, 98SE or any other type of directory structure. I can't recall what the variable to use for that directory is, but if we want it to work out of the box, it might be good to use it in this instance. Granted, most users who name their windows install directory something other than the default windows are probably also going to know how to change the script (and that they'd probably need to do so). It's not a major change, in any case. Cheers, Bryan... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-devel Digest, Vol 29, Issue 9
>From: Werner LEMBERG <[EMAIL PROTECTED]> >The following is a list of various things which should be added or >fixed in our opinion. >. Flushright bar numbers: I've mentioned already in a previous mail > that bar numbers should be moved to the right as it was in previous > lilypond versions. >* Greetings, Great news about the development meeting. Looks like some very nice things will be coming for Lilypond. About the bar numbers, if you do decide to make numbers flush right, could there still be an option to have them flush left? In most modern percussion music printed in the states, we'd expect to see the numbers at the beginning of the bar, not at the end. Thank you for your consideration. Cheers, Bryan... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-devel Digest, Vol 26, Issue 21
>Since I noticed (and moaned about) format-mark-letter omitting the >letter I a few months ago, I've been looking for examples. And I have >yet to find ONE. Of the thirty or so pieces I've played since then, if >they had an H, it was followed either by an I or the end of the piece. >And while I haven't looked especially, I think the use of bar numbers >outnumbers the use of numbers as a rehearsal mark. So that's why the >other one's necessary. What we see is that this engraving standard has become bastardized by both bands and orchestras increasingly since the 60s. If you look at the old band scores of Holst, for instance, especially those by B&H, you'll notice they're also missing the "I." The Hammersmith comes to mind immediately as one that skips from H to J (though I can't remember if that's a Boosey score or another publisher). Modern orchestras are using I more and more, but from a performer standpoint I'd much prefer none of the media have adopted I. Does it make sense alphabetically? Yes. But in the middle of a rehearsal that's being run very swiftly it's very easy to confuse I and J if it's not typeset well. Now, having said all that I think it's a good idea to have as much flexibility as we can have if it doesn't create too much confusion in implementation. This seems straight-forward enough and as long as I don't have to use it -- fine by me. :) Cheers, Bryan... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
