PATCHES: Countdown for Jan 12th - 06:00 GMT
Hello 3764 http://code.google.com/p/lilypond/issues/detail?id=3764q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Janek Warchol push Patch: Swap 'polite' and 'l2r' variable definitions 3761 http://code.google.com/p/lilypond/issues/detail?id=3761q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Keith Ohara push LeftEdge no longer takes up space 3753 http://code.google.com/p/lilypond/issues/detail?id=3753q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Carl Peterson push Patch: Cleanup of ugly MI and SOL shaped noteheads 3745 http://code.google.com/p/lilypond/issues/detail?id=3745q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Devon Schudy push Patch: Tremolo cleanup. 3789 http://code.google.com/p/lilypond/issues/detail?id=3789q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs Liska countdown Patch: Web:Background: Reword introductory paragraph 3788 http://code.google.com/p/lilypond/issues/detail?id=3788q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs Liska countdown Patch: Web:Reviews: Add title box 3787 http://code.google.com/p/lilypond/issues/detail?id=3787q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs Liska countdown Patch: Web:Productions: Add title box 3786 http://code.google.com/p/lilypond/issues/detail?id=3786q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs Liska countdown Patch: Web:Examples: Enclose in box 3785 http://code.google.com/p/lilypond/issues/detail?id=3785q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs Liska countdown Patch: Web:Introduction: Rename Our Goal box 3782 http://code.google.com/p/lilypond/issues/detail?id=3782q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation David Kastrup countdown Patch: NR: Update percussion section to make use of issue 3648 3781 http://code.google.com/p/lilypond/issues/detail?id=3781q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement james Lowe countdown Patch: Doc: NR Tidy up of Midi 3.5.x sections 3780 http://code.google.com/p/lilypond/issues/detail?id=3780q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup countdown Patch: Allow use of Scheme expressions as chord constituents Backport_2_18_1 3779 http://code.google.com/p/lilypond/issues/detail?id=3779q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement james Lowe countdown Patch: Web: Replaced Debian Logo w/the 'open use' version 3776
Re: Run grand-replace to update copyright
On Sun, Jan 05, 2014 at 10:38:04AM +0100, Werner LEMBERG wrote: I do not believe that there is a notion of package copyright in most countries' laws. On page http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html I see this: To update the list of year numbers, add each year in which you have ... not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year. This answers it, doesn't it? Indeed it does. My apologies for missing that paragraph. - does lilypond follow the GNU maintainers' guide? I hope so. If we don't, we should access our working routines. I don't think we discuss the copyright range format in our README.txt, so that's one instance in which we don't follow it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Introduction: Rename Our Goal box (issue 48430043)
LGTM https://codereview.appspot.com/48430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Background: Reword introductory paragraph (issue 48360044)
LGTM https://codereview.appspot.com/48360044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Examples: Enclose in box (issue 48450044)
LGTM https://codereview.appspot.com/48450044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Productions: Add title box (issue 38560044)
LGTM https://codereview.appspot.com/38560044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Web: Replaced Debian Logo w/the 'open use' version (issue 43990047)
LGTM, thanks for taking care of this! Note that once this is pushed, that script that updates the pictures in lilypond-extra git will need to run. It _shouldn't_ require any manual attention on lilypond.org. https://codereview.appspot.com/43990047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: simplify \score description, matching its current syntax (issue 47900043)
LGTM https://codereview.appspot.com/47900043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: CG: Add information on texlive-lang-cyrillic (Issue 3774) (issue 47870045)
LGTM https://codereview.appspot.com/47870045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: CG: Add mirror for LilyDev (Issue 3775) (issue 47890043)
LGTM https://codereview.appspot.com/47890043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
redirect old /web/ to homepage - issue 1272 (issue 47860043)
probably ok, but I'm not an expert on .htaccess.
Note that Phil will need to run update security scripts or whatever
they're called. trusted-scripts, maybe. All the steps should be
documented in the CG website section on uploading on security.
https://codereview.appspot.com/47860043/diff/1/Documentation/web/server/lilypond.org.htaccess
File Documentation/web/server/lilypond.org.htaccess (right):
https://codereview.appspot.com/47860043/diff/1/Documentation/web/server/lilypond.org.htaccess#newcode75
Documentation/web/server/lilypond.org.htaccess:75: RewriteRule ^(/*)$
%{ENV:WEB}/ [QSA,L]
I'm not too clear on this stuff. Did we define ENV:WEB somewhere?
https://codereview.appspot.com/47860043/diff/1/Documentation/web/server/robots.txt
File Documentation/web/server/robots.txt (right):
https://codereview.appspot.com/47860043/diff/1/Documentation/web/server/robots.txt#newcode23
Documentation/web/server/robots.txt:23: Disallow: /doc/v2.15/
we probably want to add /doc/v2.16/ and /doc/v2.17/ as well.
https://codereview.appspot.com/47860043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
3.0?
Please don't beat me up, but that's something I wondered about for quite some time: Is there _any_ notion what a LilyPond 3.0 may be? I mean 2.0 followed on 1.8, and now we're already towards .20 Is there any general idea about what would make the next major program version? Urs -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
LP version predicates
Is there already a clean way to let LilyPond/Scheme code be executed depending on the version number of the currently executed LilyPond? If not, would it be useful/acceptable to include something like https://github.com/openlilylib/snippets/blob/master/general-tools/lilypond-version-predicates/definitions.ily into LilyPond? That makes possible to write something like (if (lilypond-greater-than? '(2 16 0)) ... ) -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, or accept another native input language like the lilypond-driven fixed fresh release of MusicXML 4.0; something like that would warrant 3.0. I mean 2.0 followed on 1.8, and now we're already towards .20 We had major language changes and a deep incorporation of Guile, those made good excuses to move away from the 1.0 series. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
- Original Message - From: Urs Liska u...@openlilylib.org To: LilyPond Development Team lilypond-devel@gnu.org Sent: Thursday, January 09, 2014 10:53 AM Subject: 3.0? Please don't beat me up, but that's something I wondered about for quite some time: Is there _any_ notion what a LilyPond 3.0 may be? I mean 2.0 followed on 1.8, and now we're already towards .20 Is there any general idea about what would make the next major program version? Urs Fundamental changes to the approach taken? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen: Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, Hm, this is something I was also thinking about: Of course LilyPond itself will never get graphical editing but remains a dedicated engraving tool. But it would probably make it more attractive for the consumer market if it had a nice default GUI. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic? or accept another native input language like the lilypond-driven fixed fresh release of MusicXML 4.0; something like that would warrant 3.0. In that context: Does anybody have experience/knowledge/contact with MEI (www.music-encoding.org)? I mean 2.0 followed on 1.8, and now we're already towards .20 We had major language changes and a deep incorporation of Guile, those made good excuses to move away from the 1.0 series. Ah, OK: Urs Jan -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
midi control done twice
Using tt.ly:
\version 2.19.0
\score {
\new Staff {
\set Staff.midiInstrument = #electric bass (finger) % 34
\set Staff.midiPanPosition = #0
a'1
}
\midi { }
}
and midi.pl:
#!/usr/bin/perl -w
use strict;
use MIDI;
my $file;
foreach $file (@ARGV) {
my $opus = MIDI::Opus-new({ 'from_file' = $file });
$opus-dump({ dump_tracks = 1 });
}
gives me:
$ lilypond tt.ly
$ midi.pl tt.midi
MIDI::Opus-new({
'format' = 1,
'ticks' = 384,
'tracks' = [ # 2 tracks...
# Track #0 ...
MIDI::Track-new({
'type' = 'MTrk',
'events' = [ # 5 events.
['track_name', 0, 'control track'],
['text_event', 0, 'creator: '],
['text_event', 0, 'GNU LilyPond 2.19.0 '],
['time_signature', 0, 4, 2, 18, 8],
['set_tempo', 0, 100],
]
}),
# Track #1 ...
MIDI::Track-new({
'type' = 'MTrk',
'events' = [ # 10 events.
['patch_change', 0, 0, 33],
['control_change', 0, 0, 10, 64],
['control_change', 0, 0, 42, 0],
['patch_change', 0, 0, 33],
['instrument_name', 0, 'electric bass (finger)'],
['control_change', 0, 0, 10, 64],
['control_change', 0, 0, 42, 0],
['control_change', 0, 0, 7, 100],
['note_on', 0, 0, 69, 90],
['note_on', 1536, 0, 69, 0],
]
}),
]
});
$
As seen by the output, patch_change and control messages for panning
(10 is pan MSB, 42 is LSB pan) are done twice.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Jan 9, 2014, at 1:07 PM, Urs Liska u...@openlilylib.org wrote: Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen: Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, Hm, this is something I was also thinking about: Of course LilyPond itself will never get graphical editing but remains a dedicated engraving tool. But it would probably make it more attractive for the consumer market if it had a nice default GUI. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic”? GUI agnostic - there should be a clear separation between front end and backend. LilyPond is technically already GUI agnostic, as joe and vim (my two favorite GUIs) both act commendably as front ends to my LilyPond code. The best thing, by far, would to make LilyPond a modular engraving library with public APIs for each module. This way, building a GUI just means mapping visual symbols to API calls and displaying the result. GUIDO (for which I’m a developer) already works like this and has been embedded in several commercial and open-source apps. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Thu, Jan 09, 2014 at 12:07:07PM +0100, Urs Liska wrote: But it would probably make it more attractive for the consumer market if it had a nice default GUI. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic? I don't think that such a step would be conceptually acceptable (we could always provide a stripped down binary package without the editor). However, cross-compiling and distributing Frescobaldi would be a huge undertaking. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Images on Introduction and Features
Am 07.01.2014 10:31, schrieb Urs Liska: Original-Nachricht Betreff: Re: Images on Introduction and Features Datum: Tue, 07 Jan 2014 10:30:51 +0100 Von: Urs Liska u...@openlilylib.org An: Graham Percival gra...@percival-music.ca Am 03.01.2014 15:37, schrieb Urs Liska: Graham Percival gra...@percival-music.ca schrieb: On Fri, Jan 03, 2014 at 02:49:35PM +0100, u...@openlilylib.org wrote: The images in the first text boxes on Introduction and Features are the same. Is there any specific reason for this? nah, I was just copying material from the old website to the new website. It makes sense to use different images. IMHO the 'flat-design.png' is much more suitable for Features. On Introduction we're talking about freeing from the details of layout, and it's somewhat contradictory to display an image beside that which *is* about tiny details. I slightly disagree there; showing that we have a mathematical representation of the tiny details *does* mean that humans are freed from dealing with it (since computers can do it). But I agree that might not be an obvious conclusion for non-programmers, so I have no objection to using a different image there. Good point. Maybe that can easily be made clear through the text. I'll consider this when I'm at that text anyway. I'd be happy to keep that image on introduction - it's so beautyful. I think my current patch (https://codereview.appspot.com/48430043/) would allow to keep the flat-design.png on Introduction. Would you think one of the images on that page http://www.musicprintinghistory.org/engraving/about-music-engraving.html (I'd prefer fig. 3 or 4) would be suitable for Features? And would the Use of Information make it suitable for inclusion in our website? Any opinions? However, independently from this concrete image: What is the way to add new images to the website/docs? I suppose they somehow have to get into the lilypond-extra repo? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Images on Introduction and Features
- Original Message - From: Urs Liska u...@openlilylib.org However, independently from this concrete image: What is the way to add new images to the website/docs? I suppose they somehow have to get into the lilypond-extra repo? Yes, IIRC. I can do that, as can GP. I don't know who else has push access. It always takes me ages to remember how to push to that repo, though. I believe the work flow is that you must get the image into the -extra repo before pushing any changes that would use that image to staging/master. If you do this the other way round, the build of the actual website will fail. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska u...@openlilylib.org writes: Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen: Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, Hm, this is something I was also thinking about: Of course LilyPond itself will never get graphical editing but remains a dedicated engraving tool. But it would probably make it more attractive for the consumer market if it had a nice default GUI. It's not for the consumer market anyway. Too much thinking. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Frescobaldi is not a GUI but an IDE. It runs on fewer platforms than LilyPond. Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic? That question does not make sense. You don't describe such a step, I don't see what concepts are involved here, and there is no point in not adding support code for particular applications. One problem with GUI proponents is that they more often than not are of the opinion it should work good on Windows, let the rest be d***ed, and it is the position of the GNU project _not_ to introduce material that promotes the use of proprietary platforms over free ones. Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska u...@openlilylib.org writes: Please don't beat me up, but that's something I wondered about for quite some time: Is there _any_ notion what a LilyPond 3.0 may be? I mean 2.0 followed on 1.8, and now we're already towards .20 Is there any general idea about what would make the next major program version? Not without GUILEv2 and likely some other architectural overhaul. The early 2.0 phase mostly got rid of TeX. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson:
...
Now, consider an IDE/GUI setup
(perhaps an extension of Frescobaldi) that would allow me to define a
variable for a voice, then pop up a musical staff to enter and play
back the notes for that variable without dealing with the whole
compilation process. No manual tweaking of notes, just the entry of
the entry and playback of the notes, and I don't have to insert the
notes into the music itself yet or deal with whatever may or may not
be wrong with the rest of my file. I realize that this would not
necessarily work for all use cases, but I think for a large number of
them, this could be beneficial. It would reduce a number of my
transcription errors without me having to compile, scan for errors,
potentially figure out where the errors are (depending on workflow),
correct, recompile, etc.
Sounds like a performance problem, you want to hear (quickly) how the
things you entered sounds. That can be done with lilypond as is, just
skip the ps/pdf generation, us a test file like:
ma = { your_music }
targetpitch = c
midi_tempo = { \tempo 2 = 100 }
\score {
\unfoldRepeats \transpose c \targetpitch
\new Staff \ma
\midi {
\midi_tempo
}
}
///
As an example take:
http://turkos.aspodata.se/git/musik/ALotti/missa_a3_la_minore/
Compiling it takes 15s on my box.
$ time lilypond 01_kyrie.ly
GNU LilyPond 2.19.0
Processing `01_kyrie.ly'
real0m14.844s
user0m10.914s
sys 0m0.291s
Skipping the to-pdf conversion saves me 2s
$ time lilypond --ps 01_kyrie.ly
...
real0m12.674s
user0m9.368s
sys 0m0.220s
And doing only midi is fast, 2.5s:
$ time lilypond 01_kyrie.ly
GNU LilyPond 2.19.0
Processing `01_kyrie.ly'
Parsing...
Interpreting music...
MIDI output to `01_kyrie.midi'...
Success: compilation successfully completed
real0m2.437s
user0m1.652s
sys 0m0.140s
So running
$ lilypond file.ly timidity file.midi
would probably solve your stated need.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
David Kastrup d...@gnu.org schrieb: Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. LOL! -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Background: Reword introductory paragraph (issue 48360044)
LGTM https://codereview.appspot.com/48360044/diff/1/Documentation/web/introduction.itexi File Documentation/web/introduction.itexi (right): https://codereview.appspot.com/48360044/diff/1/Documentation/web/introduction.itexi#newcode554 Documentation/web/introduction.itexi:554: This is interesting reading if you are interested in an in-depth there are two 'interesting' in this sentence. Maybe change first one to 'informative'? (just a suggestion, not a requirement) https://codereview.appspot.com/48360044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Productions: Add title box (issue 38560044)
LGTM https://codereview.appspot.com/38560044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: redirect old /web/ to homepage - issue 1272 (issue 47860043)
Reviewers: Graham Percival,
https://codereview.appspot.com/47860043/diff/1/Documentation/web/server/lilypond.org.htaccess
File Documentation/web/server/lilypond.org.htaccess (right):
https://codereview.appspot.com/47860043/diff/1/Documentation/web/server/lilypond.org.htaccess#newcode75
Documentation/web/server/lilypond.org.htaccess:75: RewriteRule ^(/*)$
%{ENV:WEB}/ [QSA,L]
On 2014/01/09 09:42:54, Graham Percival wrote:
I'm not too clear on this stuff. Did we define ENV:WEB somewhere?
at the beginning of the rewrite rules I see:
SetEnvIf REQUEST_URI .* WEB=/website
WEB used to be /web, then it changed to /website (and someone forgot to
edit the comments accordingly).
Description:
redirect old /web/ to homepage - issue 1272
Also disable indexing of /web/
Please review this at https://codereview.appspot.com/47860043/
Affected files (+10, -5 lines):
M Documentation/web/server/lilypond.org.htaccess
M Documentation/web/server/robots.txt
Index: Documentation/web/server/lilypond.org.htaccess
diff --git a/Documentation/web/server/lilypond.org.htaccess
b/Documentation/web/server/lilypond.org.htaccess
index
5e7dfae3d98773b58516b45122318f187bfd7716..d4ba378dbef4277ef0235dc5c45e400cc08ad6b1
100644
--- a/Documentation/web/server/lilypond.org.htaccess
+++ b/Documentation/web/server/lilypond.org.htaccess
@@ -61,7 +61,7 @@ RedirectMatch ^/index$ /
###
-## Rewrite all non-existing files at toplevel to the /web/ dir, so our
+## Rewrite all non-existing files at toplevel to the /website/ dir, so our
## internal structure for rsync doesn't have to be changed.
## This works for the current/old site as well as the new one.
@@ -70,7 +70,7 @@ RewriteBase /
SetEnvIf REQUEST_URI .* WEB=/website
-# Rewrite empty to /web
+# Rewrite empty to /website
RewriteCond %{REQUEST_URI} ^/*$
RewriteRule ^(/*)$ %{ENV:WEB}/ [QSA,L]
@@ -80,12 +80,12 @@ RewriteCond %{REQUEST_URI} ^/?[^/]+[.]css$
RewriteCond %{REQUEST_FILENAME} !-f
# ...and does not match an existing directory
RewriteCond %{REQUEST_FILENAME} !-d
-# ...prefix with web
+# ...prefix with website
RewriteRule ^(.+)$ %{ENV:WEB}/$1 [QSA,L]
# Request without trailing slash
RewriteCond %{REQUEST_URI} !.*/$
-# ...that would access a directory in /web
+# ...that would access a directory in /website
RewriteCond %{DOCUMENT_ROOT}%{ENV:WEB}%{REQUEST_URI} -d
# ...and does not start with /web
RewriteCond %{REQUEST_URI} !^%{ENV:WEB}
@@ -95,7 +95,7 @@ RewriteCond %{REQUEST_URI} !^/doc$
# ...add trailing slash for [menu] and to avoid /web/ in browser url
RewriteRule ^(.+)$ http://%{HTTP_HOST}/$1/ [R,QSA,L]
-# Request that does not start with /web
+# Request that does not start with /website
RewriteCond %{REQUEST_URI} !^/website
RewriteCond %{REQUEST_URI} !^%{ENV:WEB}
# ...and does not start with /doc/
@@ -109,6 +109,9 @@ RewriteCond %{REQUEST_FILENAME} !-d
# ..prefix with /web
RewriteRule ^(.+)$ %{ENV:WEB}/$1 [QSA,L]
+## Redirect the old web/ to the homepage
+RedirectMatch 301 /web/* /
+
###
# latin1 version copied to web and doc/2.x
Index: Documentation/web/server/robots.txt
diff --git a/Documentation/web/server/robots.txt
b/Documentation/web/server/robots.txt
index
ccc8ed800dd36032733f74e5ba6d2dad63e61f73..8213d0e215d5b6684347dd98dbb1279ae743402e
100644
--- a/Documentation/web/server/robots.txt
+++ b/Documentation/web/server/robots.txt
@@ -21,3 +21,5 @@ Disallow: /doc/v2.12/
Disallow: /doc/v2.13/
Disallow: /doc/v2.14/
Disallow: /doc/v2.15/
+
+Disallow: /web/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On 09/01/14 21:05, David Kastrup wrote: That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. I'm not sure that I feel happy about your benchmark for comparison. I think Lilypond's user base is a bit smarter than that ... ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
dak wrote Joseph Rushton Wakeling lt; joseph.wakeling@ gt; writes: On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@ https://lists.gnu.org/mailman/listinfo/lilypond-devel I honestly have never seen ONE Word document make use of styles. I'm not kidding. In all the docs I've come across in all areas, people never use them. Seriously! :) Now, LibreOffice Writer on the other hand... - composer | sound designer LilyPond Tutorials (for beginners) -- http://bit.ly/bcl-lilypond -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157553.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson wrote I use MuseScore, Scorio, and Finale Notepad (depending on where I am and how I feel) for compositional work because they provide ease of note entry in the composing process and the ability to have instant aural feedback on what I've written (particularly if I'm not at my keyboard to play what I've written). Once I have the draft of the music written, I will manually retype the music into my LilyPond template because of the good default typesetting it provides. Hi Carl, Do you find that manually retyping is easier or better than export - musicXML - import? Curious to hear your thoughts as I would assume that import/export would be the ideal way to use a workflow like this. Thanks, -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157554.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
