(geen onderwerp)
[to lilypond-devel, not sure if everyone is subscribed to lilypond-hacker] Graham Percival schreef: I've finished most of the doc work. There's still plenty of things to do, but they're not so urgent. I can start doing bug stuff now. Until the bug tracker is up, what should I do? I had another look at the roundup demo, and there's a few fields that could be changed (less bug status flags, removing the nosy field (I don't know what it's supposed to do)), but my general impression is that I won't know what should be changed until I actually use it for a week or two. Besides, the nosy field is a list of people to email the bug discussion about. It's very useful, because the tracker will appear like a subscription mailing for reporters, but only for their bugs. we don't want this running on my laptop anyway. Han-Wen, what's the status of the bug tracker? It still has no status. I've been playing with the demo too. Because it will be on a real server, I'll have to make a list of things to do (database interfaces, cgi-bin vs. standalone server, email aliases) so we can tell our hosting provider what we need. Then we have to set everything up, migrate bugreports, change references etc. Then, we need to have a run lilypond on open bugreports server. Do we have a vague estimate on a 2.10 release? I'm looking at a _very_ vague answer, such as fall or beginning of 2007. I'm wondering how No, the way things are going, we can time the 2.10 release whenever we want: as long as we keep lily stable (ie. keep make web working), it should be possible to push out 2.10 on -say- a month's notice. That being said, I'm hoping for the following additions for 2.10 - optimal page breaking - music stream I/O - parser work by Erik - geometric regression testing (I think I asked David Feuer about this, but he has been remarkably silent) also, I was hoping to rewrite some of the logic for toplevel music, \score and \book. Since things also depend on some personal plans for me, it makes sense to do the 2.10 release 'soon', as in: early summer. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme chapter: material for deletion
Graham Percival [EMAIL PROTECTED] writes: On 19-May-06, at 1:31 PM, Mats Bengtsson wrote: In that case, make sure to also delete the examples in input/*/ that use \applyMusic, otherwise you will cause some confusion (of course, some of these examples may be useful and should preferably be rewritten as music functions instead). \applyOutput is mentioned in 9.2.2 Creating contexts; is this reference worth keeping? Note that I'm not really familiar with \apply*, so I'm not in a good position to judge whether they should be kept in the docs or not. Even if we decide to remove references to \apply* in the docs and in input/test/, I'm not going to touch input/regresssion/ :) \applyMusic was the music function ancestor: you could apply a unary function to a single music expression. So it is sort of useless now, unless I'm missing something. Keep sections on \applyContext and \applyOutput, because they have nothing to do with music expressions, they apply to other types of objects. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme chapter: material for deletion
\applyMusic was the music function ancestor: you could apply a unary function to a single music expression. So it is sort of useless now, unless I'm missing something. As long as all old useful examples that use the \applyMusic feature are not rewritten into music functions, it may certainly be useful for some people. On the other hand, keeping \applyMusic in the implementation but removing it from the documentation may be a good way to phase it out. /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Cautionary accidentals in Ambitus
Hi folks,
I've recently written a timpani part for a score I'm writing, and I thought I'd
add an ambitus to the beginning of the part to show the necessary tuning (I
know, it's not standard!)
The two notes I want the timps tuned to are aes and des, and the key is des
major. However, because the key signature (which comes _after_ the ambitus)
includes aes and des there are no flats on the ambitus. How do I add cautionary
accidentals?
I notice in the programme reference that Ambitus_engraver has a setting for
cautionary accidentals, but it doesn't tell me how to turn them on or off.
Here's a simple version of my code:
\version 2.9.4
\score{
\relative c {
\clef bass
\key des \major
des aes des aes |
}
\layout{
\context {
\Voice
\consists Ambitus_engraver
}
}
}
--
=
Cameron Horsburgh
/dev/random says:
Dinner not ready: (A)bort (R)etry (P)izza
http://web.netcall.com.au/horsburgh
_ _ _ _ _
/ ___| _ __ ___ (_) | ___| | | |
\___ \| '_ ` _ \| | |/ _ \ | | |
___) | | | | | | | | __/_|_|_|
|/|_| |_| |_|_|_|\___(_|_|_)
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cautionary accidentals in Ambitus
Hi,When I write timpani parts I specify the tuning this way:tuning = \markup { \score { \new Staff \with { \remove Time_signature_engraver } { \set Staff.instrument = Tuning:
\clef bass { b,4 d e a } } \layout { ragged-right = ##t } }}\header { poet = \markup { \tuning }}I know it doesn't answer your question, but I thought you might find it interesting anyway.
Regards, Erlend AaslandOn 5/20/06, Cameron Horsburgh [EMAIL PROTECTED] wrote:
Hi folks,I've recently written a timpani part for a score I'm writing, and I thought I'd add an ambitus to the beginning of the part to show the necessary tuning (I know, it's not standard!)
The two notes I want the timps tuned to are aes and des, and the key is des major. However, because the key signature (which comes _after_ the ambitus) includes aes and des there are no flats on the ambitus. How do I add cautionary accidentals?
I notice in the programme reference that Ambitus_engraver has a setting for cautionary accidentals, but it doesn't tell me how to turn them on or off.Here's a simple version of my code:\version
2.9.4\score{\relative c {\clef bass\key des \majordes aes des aes |}\layout{\context {\Voice\consists Ambitus_engraver}
}}--=Cameron Horsburgh/dev/random says:Dinner not ready: (A)bort (R)etry (P)izzahttp://web.netcall.com.au/horsburgh
_ __ _ _/ ___| _ __ ___ (_) | ___| | | |\___ \| '_ ` _ \| | |/ _ \ | | | ___) | | | | | | | |__/_|_|_||/|_| |_| |_|_|_|\___(_|_|_)=
___lilypond-devel mailing listlilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Realtime display
Austin Taylor schreef: Hello, My high-level goal is to display music notation in Cocoa, quickly. I'd like to use LilyPond for printing at some point, so using it for display seems very natural. However, LilyPond seems to only work with files. I haven't run any tests yet, but I'm thinking it would be way too slow to write my input to a file, fire up lilypond, and then read its output from disk and display it. The obvious thing would be to keep a lilypond process alive, pipe it stuff, and get output (probably pdf) from standard out that I can send to Quartz. Of course, that still might not be fast enough. There would be other possible optimizations from there. I will only be changing little bits of the score at a time. So my questions are: 1. Is LilyPond even the right tool for the job? 2. Is there a way to do this already? 3. Would realtime display be feasible even if this were implemented? 4. How much would it cost to have it implemented? This is possible, there's a demo module ikebana in CVS that use Python+GTK to display interactive music notation, using the socket backend (a backend that reads LISP from a network connection and sends back the result over the same connection in a custom format). Lily does not have any hooks or support for incremental rendering, so I'm not sure if you could make it fast enough. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
