Re: 3.0?
2014/1/12 Carl Peterson carlopeter...@gmail.com: What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. I think this is exactly a Denemo thing. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com writes: 2014/1/12 Carl Peterson carlopeter...@gmail.com: What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. I think this is exactly a Denemo thing. Well, the question is how much one could pluginize Denemo. Like, marking a passage in Emacs which then turns into a small Denemo display window (the keyboard commands would still travel via Emacs) and back again... This could be interesting technology... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com schrieb: 2014/1/12 Carl Peterson carlopeter...@gmail.com: What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. I think this is exactly a Denemo thing. Please add your doubts to the Frescobaldi issue. Urs best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
2014/1/10 Urs Liska u...@openlilylib.org: Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. I know that this is not exactly what we're talking about, but i believe that things like this (previewing music, partially compiled scores, instant feedback sacrificing some quality) are exactly what Denemo is for. I honestly believe that Denemo would be invaluable to LilyPond if only it could open all Lily files, not just those created by itself. (and if the UIUX kinks would be ironed out). best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com writes:
2014/1/10 Urs Liska u...@openlilylib.org:
Well,
compiling a few measures of a single staff feels nearly instantaneous, and
when you're editing an orchestral score this makes a huge difference.
Generally I'd think it would be a good idea to have such an interface in
Frescobaldi.
I know that this is not exactly what we're talking about, but i
believe that things like this (previewing music, partially compiled
scores, instant feedback sacrificing some quality) are exactly what
Denemo is for. I honestly believe that Denemo would be invaluable to
LilyPond if only it could open all Lily files, not just those created
by itself. (and if the UIUX kinks would be ironed out).
One very nice integrated experience is offered by preview-latex
URL:http://www.gnu.org/software/auctex/preview-latex. preview-latex
has no clue about the documents itself and does not actually import
them. It does not parse them and does not touch the input or create a
representation of it. There are several things it does for fast update
of single items (the first run is per-document, though):
a) it dumps a preloaded format including all document classes and
document styles, namely everything before \begin{document}. This
operation is optional.
b) When rerunning material in a single item, it cuts it out, precedes it
with what it considers the document preamble, follows it by what it
considers the document ending, and runs that through. That means,
obviously, that any macros you refer to have to be defined in the
document preamble or stuff won't work. It's quite uncommon to arrange
a LaTeX source using actual macros, so that usually works pretty well.
When wanting to do that approach using LilyPond, the preloaded format
thing can be accommodated quite better than with TeX (which is taken
as-is as a binary): we can just have a LilyPond process waiting for
action, and use the session mechanism for providing a reasonably
prepared situation without needing a new process each time.
The problem is that LilyPond sources more often than not _are_ arranged
with macro definitions, so we need to get those dependencies right.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Jan 10, 2014, at 11:41 PM, Paul Morris p...@paulwmorris.com wrote: Seems like getting just the notes (not layout) out of an imported musicXML file should be an easy and straightforward thing, but I guess not? I can't speak for Carl P's work. For me, effective LP input files require structure (variables, contexts) that MusicXML knows nothing of. And it's generally easier to create them than to fix them on import. Carl S. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
2014/1/11 David Kastrup d...@gnu.org: One very nice integrated experience is offered by preview-latex URL:http://www.gnu.org/software/auctex/preview-latex. Indeed, this is very nice. Although i haven't used it, i know i would enjoy it :) j ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com writes: 2014/1/11 David Kastrup d...@gnu.org: One very nice integrated experience is offered by preview-latex URL:http://www.gnu.org/software/auctex/preview-latex. Indeed, this is very nice. Although i haven't used it, i know i would enjoy it :) Well, actually it's a lot better than you'd guess from the screenshots: the proof-of-concept took about two weeks, and the screen shots would not have been much different then (apart from the descenders being wrong). There's been years of development going into it afterwards. It's technology that does not get in the way, is fast and reliable, and integrates with personal workflows seamlessly. I wish we'd have something like that for the LilyPond manuals. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Am Donnerstag, den 09.01.2014, 10:13 -0500 schrieb Carl Peterson: On Thu, Jan 9, 2014 at 6:20 AM, David Kastrup d...@gnu.org 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 don't know that I agree with this, entirely. 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. 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. Carl https://github.com/wbsoft/frescobaldi/issues/345 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Sorensen-3 wrote I can't speak for Carl P's work. For me, effective LP input files require structure (variables, contexts) that MusicXML knows nothing of. And it's generally easier to create them than to fix them on import. I see what you mean. Unfortunately it makes it harder to use other tools that are optimized for composing with LilyPond... Seems like capturing just the musical content from a MusicXML file and then pasting it into a LP template or file that has the LP structure should be easier than re-typing it. But I defer to those with more experience in this area, as I've only done musicXML import a few times. David Kastrup wrote One very nice integrated experience is offered by preview-latex lt;URL:http://www.gnu.org/software/auctex/preview-latexgt;. snip I wish we'd have something like that for the LilyPond manuals. This does look good. It would be really nice to have something like this for the manuals. Urs Liska wrote https://github.com/wbsoft/frescobaldi/issues/345 I'm not sure about this. Seems like you could get basically the same workflow by using a second file as a sketchpad without having to introduce a new UI component. See my comment at the link above for more of my thoughts on this. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157682.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?
On Sat, Jan 11, 2014 at 11:50 PM, Paul Morris p...@paulwmorris.com wrote: Carl Sorensen-3 wrote I can't speak for Carl P's work. For me, effective LP input files require structure (variables, contexts) that MusicXML knows nothing of. And it's generally easier to create them than to fix them on import. I see what you mean. Unfortunately it makes it harder to use other tools that are optimized for composing with LilyPond... Seems like capturing just the musical content from a MusicXML file and then pasting it into a LP template or file that has the LP structure should be easier than re-typing it. But I defer to those with more experience in this area, as I've only done musicXML import a few times. Urs Liska wrote https://github.com/wbsoft/frescobaldi/issues/345 I'm not sure about this. Seems like you could get basically the same workflow by using a second file as a sketchpad without having to introduce a new UI component. See my comment at the link above for more of my thoughts on this. -Paul Allow me to extend my use case a bit further. My own work is similar to what I understand of Carl S's work. I have a file where I define each of my SATB parts, each lyrical verse, and calls a template file that takes the parts and creates the two staves for the music, with both a part-combined voice for display purposes and separated voices for MIDI and lyric purposes (the separated notes are hidden and non-colliding, etc., in the layout). I have a second file where I include this master file and create either the paper hymnal layout or slides for projection (depending upon which layout template I call). I've done the two file workflow before, typically when I've created the four parts using a basic SATB template, then copied and pasted into the variables of my own template. That said, I am also trying to think about features which would make this more productive for someone who *isn't* inclined to work multiple files, variables, etc. What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. Since Denemo is already a GUI experience, it may be the better place to try to get this kind of functionality. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Fri, Jan 10, 2014 at 12:46 AM, Paul Morris p...@paulwmorris.com wrote: 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. Retyping by far. I pretty much write exclusively a cappella SATB, and I have developed a very specific template/workflow for the part combining and layout. I've tried a few different ways of getting the music from these formats into LP, and in each case, I found myself spending longer in cleaning up the resulting LilyPond code than if I had just transcribed it manually from the other program. That is why I suggested an IDE feature that would allow for creating a variable, and then providing a basic visual note-entry tool that can handle single or chorded notes (whether it allows polyphonic music may be a more challenging question), then return minimal code (just the notes). I know someone suggested just turning off the PDF conversion to speed things up, but it's not just a matter of instantaneous aural feedback. There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson: ... I know someone suggested just turning off the PDF conversion to speed things up, but it's not just a matter of instantaneous aural feedback. Ok. There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. A quick-n-dirty test mode would probably solve your need, just to check for typing errors and such (as you write above). What should such a mode need/disregard, what speedups are possible for such a test mode ? 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?
Am 10.01.2014 22:23, schrieb k...@aspodata.se: Carl Peterson: ... I know someone suggested just turning off the PDF conversion to speed things up, but it's not just a matter of instantaneous aural feedback. Ok. There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. A quick-n-dirty test mode would probably solve your need, just to check for typing errors and such (as you write above). What should such a mode need/disregard, what speedups are possible for such a test mode ? Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? Urs 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 -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson: ... Retyping by far. I pretty much write exclusively a cappella SATB, and I have developed a very specific template/workflow for the part combining and layout. I've tried a few different ways of getting the music from these formats into LP, and in each case, I found myself spending longer in cleaning up the resulting LilyPond code than if I had just transcribed it manually from the other program. ... What if the midi-lilypond conversion could be made better? I'm currently looking into that. 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?
Urs Liska: Am 10.01.2014 22:23, schrieb k...@aspodata.se: Carl Peterson: ... There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. A quick-n-dirty test mode would probably solve your need, just to check for typing errors and such (as you write above). What should such a mode need/disregard, what speedups are possible for such a test mode ? Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Denpends on the computer you are using, http://turkos.aspodata.se/git/musik/ALotti/missa_a3_la_minore/04_agnus.ly is 17bars, 3voices with lyrics, and it still takes 5s on my box, Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? If you are only interested in checking octaves and durations, the context doesn't matter too much. 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 1/9/14 9:43 PM, SoundsFromSound soundsfromso...@gmail.com wrote: dak wrote Joseph Rushton Wakeling lt;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 ___ 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! :) I use styles anytime I have to make a serious Word document (i.e. when I can't use LaTeX). Of course, that's probably part of the reason that I like LilyPondŠ. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Fri, Jan 10, 2014 at 4:25 PM, Urs Liska u...@openlilylib.org wrote: Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? Couple of possibilities. Just thinking about Frescobaldi, since it seems to do a pretty good job of tracing things through the document(s), would it be possible to look for the reference to that variable and try to determine the context? Another option is that this is not a compilation feature (i.e., Fresco is not passing the variable to LP to compile), but rather it would allow a dialog box/popup and there would be the option to change certain things like time signature, transposition, etc. I actually think it should be some kind of bare-bones parser apart from LP proper (a bypass) that doesn't factor in articulations, manual tweaks, etc., but only considers absolutely essential components (notes, slurs, ties, chords, etc.). Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Am 10.01.2014 23:37, schrieb Carl Peterson: On Fri, Jan 10, 2014 at 4:25 PM, Urs Liska u...@openlilylib.org wrote: Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? Couple of possibilities. Just thinking about Frescobaldi, since it seems to do a pretty good job of tracing things through the document(s), would it be possible to look for the reference to that variable and try to determine the context? I think that wouldn't be reliable because there are so many possibilities one couldn't really preview. Another option is that this is not a compilation feature (i.e., Fresco is not passing the variable to LP to compile), but rather it would allow a dialog box/popup and there would be the option to change certain things like time signature, transposition, etc. I actually think it should be some kind of bare-bones parser apart from LP proper (a bypass) that doesn't factor in articulations, manual tweaks, etc., but only considers absolutely essential components (notes, slurs, ties, chords, etc.). Carl Actually I think you're considering something like Denemo does: create a mock-up editor with output that will later be replaced by LilyPond's output. But now I see how it could be done. What you want is a tool that creates LilyPond input for you, isn't it? Like the keyboard is a tool, midi input is one and xml import is one. So you don't actually need the segment to be taken from the real file or even be related to it. What Frescobaldi can do is take some input code, put it in a scratch area and let LilyPond compile that as a temporary file. That's what it does when you compile a file that doesn't have a name yet. Or when you're in the New Score Wizard and click Preview. So what one could implement is a tool that provides some, but not too much space to edit text, a small preview pane and a set of UI elements for setting the musical context. From there it can wrap the source in a score template, respecting the settings of time, key etc. and compile this (maybe continuously). Then there are two buttons to copy/cut the source to the clipboard or to insert it at the current cursor position. Actually there already is a similar tool: Edit in place. When you right click on an item in the Music View and select Edit in Place it fires a small editor window where you can edit the current line in the source file. -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson wrote Retyping by far. I pretty much write exclusively a cappella SATB, and I have developed a very specific template/workflow for the part combining and layout. I've tried a few different ways of getting the music from these formats into LP, and in each case, I found myself spending longer in cleaning up the resulting LilyPond code than if I had just transcribed it manually from the other program. Hmmm, I'm curious what kind of cleanup is needed? Is it the part combining of SATB that's the problem, with the musicXML having the music represented as harmonies / chords, and needing to isolate the different parts? ...or something else? Seems like getting just the notes (not layout) out of an imported musicXML file should be an easy and straightforward thing, but I guess not? That is why I suggested an IDE feature that would allow for creating a variable, and then providing a basic visual note-entry tool that can handle single or chorded notes (whether it allows polyphonic music may be a more challenging question), then return minimal code (just the notes). This makes me wonder if Schikker's List could work for this, either as a separate tool or possibly integrated into Frescobaldi? (It's written in Scheme whereas Frescobaldi is in Python, so that may be an obstacle?) It seems that if, as Urs is suggesting here, Frescobaldi moves towards more graphical features then we're headed for some duplication of effort between it and Schikker's List. Just this week I came across LilyComp (http://lilycomp.sourceforge.net/) which I haven't tried, and is probably too simple to be much help. But if it or something like it was integrated into Frescobaldi with the new auto-compile feature, perhaps just rendering a limited number of notes at a time in a separate window, that might start to be interesting. (It's written in python and is licensed under the GPL.) -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157612.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?
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
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: 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: 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
Re: 3.0 -- gnome backend
Nicolas Sceaux writes: That's quite strange. I tested on a fresh machine. What versions of fontconfig/gnome/pango do you use? fontconfig is version 2.2.3 gnome is 2.6.1 pango is 1.4.1 ohoh, maybe I should look at guile-gnome.sh again, and get a more recent pango. I'm doing this. Yes. Does lily build with pango and show the gnome canvas? I'm amazed, it needs pango 1.5.2 or newer. LilyPond fonts do appear in the font selection dialog. Ok. This is the same mechanism, also gnome/pango, so the fonts are there. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Nicolas Sceaux writes: That's quite strange. I tested on a fresh machine. What versions of fontconfig/gnome/pango do you use? fontconfig is version 2.2.3 gnome is 2.6.1 pango is 1.4.1 ohoh, maybe I should look at guile-gnome.sh again, and get a more recent pango. I'm doing this. Yes. Does lily build with pango and show the gnome canvas? I'm amazed, it needs pango 1.5.2 or newer. My mistake. pango 1.4.1 was the debian's one. I have 1.5.0 from (old) CVS. This is the one that was used to compile LilyPond with --enable-gui. I am upgrading to pango 1.5.2. What does BLOEDIGE_RAND mean? bleeding edge? Should I use pango, g-wrap, etc, from CVS/arch or the tar.gz packages? nicolas ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Nicolas Sceaux [EMAIL PROTECTED] writes: My mistake. pango 1.4.1 was the debian's one. I have 1.5.0 from (old) CVS. This is the one that was used to compile LilyPond with --enable-gui. I am upgrading to pango 1.5.2. What does BLOEDIGE_RAND mean? bleeding edge? Should I use pango, g-wrap, etc, from CVS/arch or the tar.gz packages? Now, I have rebuilt and installed pango, g-wrap, guile-gnome: nicolas:~ pkg-config --modversion pango 1.5.2 nicolas:~ pkg-config --modversion g-wrap-2.0-guile 1.9.1 nicolas:~ pkg-config --modversion guile-gnome-glib 2.5.993 and then built again LilyPond from CVS. but still the same result. Note: this may have nothing to do with gnome and pango, but I can select LilyPond-feta in OOo Writer, and insert F-clef, dacoda signs, etc. nicolas inline: lily-gnome-capture.png___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Jan Nieuwenhuizen [EMAIL PROTECTED] writes:
That's quite strange. I tested on a fresh machine. What versions of
fontconfig/gnome/pango do you use?
fontconfig is version 2.2.3
gnome is 2.6.1
pango is 1.4.1
ohoh, maybe I should look at guile-gnome.sh again, and get a more
recent pango. I'm doing this.
PS: you may try compiling this, to see if LilyPond fonts show up in
the dialogue.
/*
gfs.c
gcc -o gfs gfs.c $(pkg-config --cflags --libs gtk+-2.0)
*/
#include gtk/gtk.h
int main(int argc, char* argv[]) {
GtkWidget *dlg;
gtk_init(argc, argv);
dlg = gtk_font_selection_dialog_new(Select font);
if (gtk_dialog_run(GTK_DIALOG(dlg)) == GTK_RESPONSE_OK) {
g_print(Selected: %s.\n,
gtk_font_selection_dialog_get_font_name(
GTK_FONT_SELECTION_DIALOG(dlg)));
}
return 0;
}
LilyPond fonts do appear in the font selection dialog.
nicolas
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Han-Wen Nienhuys writes: I recall that it wasn't so long ago that not all distributions shipped with fontconfig, which is instrumental in getting fonts from ~/.fonts/ configured correctly. That's it! xset/xlsfonts has nothing todo with gnome/pango fonts. It seems gnome-font-install doesn't either. It's the fontconfig package; lilypond fonts should show up in fc-list. My fontconfig documentation says it looks in /usr/share/fonts and ~/.fonts. To have fontconfig look in other directories, make a ~/.fonts.conf: ?xml version=1.0? !DOCTYPE fontconfig SYSTEM fonts.dtd fontconfig dir~/cvs/savannah/lilypond/lilypond/mf/out/dir /match /fontconfig (without the /match closing tag) $ cat ~/.fonts.conf ?xml version=1.0? !DOCTYPE fontconfig SYSTEM fonts.dtd fontconfig dir~/cvs/lilypond/mf/out/dir /fontconfig $ fc-cache -f $ fc-list | grep -i lilypond LilyPond\-feta\-din:style=Regular LilyPond\-feta\-braces\-a:style=Regular LilyPond\-feta\-braces\-c:style=Regular LilyPond\-feta\-braces\-b:style=Regular LilyPond\-feta\-braces\-e:style=Regular LilyPond\-feta\-braces\-d:style=Regular LilyPond\-feta\-braces\-g:style=Regular LilyPond\-feta\-braces\-f:style=Regular LilyPond\-feta\-braces\-i:style=Regular LilyPond\-feta\-braces\-h:style=Regular LilyPond\-feta\-nummer:style=Regular LilyPond\-parmesan:style=Regular LilyPond\-feta:style=Regular but still no feta glyphs displayed when invoking lilypond -fgnome. I'll try with defoma. nicolas ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0
Lilypond 2.3 is marked as broken on freebsd. Now that I'we moved to freebsd, I notice a lot more when the luxury of an up to date lilypond doesn't exist. I will try to do what I can to help straighten it out before 3.0. Has anyone heard form Patrick Atamaniuk (the freebsd packager)? I have had no luck reaching him. Han-Wen Nienhuys wrote: Hi guys, 3.0 is almost ready. For the 3.0 release 1. I've put back TeX as the default backend. I welcome patches that will Do The Right thing for encodings and landscape options of \bookpaper. 2. I will have a another look at slurs across line-breaks I propose to release 3.0 once Item 2. is dealt with. I expect this to happen in 1 to 2 weeks. Of course, if there are any very pressing bugs reported on the mailing list, I will try to fix those as well. There is also some other good news: some of the dependencies for the LilyPond GNOME backend have been released or are almost ready to be released. This means that in a short while we will have native point-and-click, without requiring TeX or DVI. ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Han-Wen Nienhuys writes: $ ln -s ~/cvs/lilypond/mf/out ~/.fonts $ mkfontdir ~/.fonts $ xset +fp ~/.fonts Something went wrong here. Does xlsfonts report the feta fonts? Could it be that this is system/distribution specific? Until we know what's wrong, it could be the cat. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
[EMAIL PROTECTED] writes: Han-Wen Nienhuys writes: $ ln -s ~/cvs/lilypond/mf/out ~/.fonts $ mkfontdir ~/.fonts $ xset +fp ~/.fonts Something went wrong here. Does xlsfonts report the feta fonts? Could it be that this is system/distribution specific? Until we know what's wrong, it could be the cat. I recall that it wasn't so long ago that not all distributions shipped with fontconfig, which is instrumental in getting fonts from ~/.fonts/ configured correctly. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Nicolas Sceaux writes: I have some troubles with it: feta fonts seem not to be found when the gnome output is displayed, although I have done: $ ln -s ~/cvs/lilypond/mf/out ~/.fonts $ mkfontdir ~/.fonts $ xset +fp ~/.fonts Something went wrong here. Does xlsfonts report the feta fonts? Yes. nicolas:~/lilypond/cesare/ly/0-1 xlsfonts | grep feta -gnu-lilypond-feta braces a-r-normal-15-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces a-r-normal-15-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces a-r-normal-15-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces a-r-normal-15-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces b-r-normal-30-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces b-r-normal-30-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces b-r-normal-30-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces b-r-normal-30-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces c-r-normal-45-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces c-r-normal-45-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces c-r-normal-45-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces c-r-normal-45-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces d-r-normal-60-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces d-r-normal-60-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces d-r-normal-60-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces d-r-normal-60-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces e-r-normal-75-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces e-r-normal-75-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces e-r-normal-75-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces e-r-normal-75-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces f-r-normal-90-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces f-r-normal-90-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces f-r-normal-90-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces f-r-normal-90-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces g-r-normal-105-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces g-r-normal-105-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces g-r-normal-105-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces g-r-normal-105-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces h-r-normal-120-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces h-r-normal-120-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces h-r-normal-120-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces h-r-normal-120-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces i-r-normal-135-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces i-r-normal-135-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces i-r-normal-135-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta braces i-r-normal-135-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-14-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-14-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-14-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-14-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-17-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-17-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-17-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-17-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-5.5-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-5.5-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-5.5-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-5.5-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-8-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-8-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-8-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta din-r-normal-8-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-10-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta nummer-r-normal-12-0-0-0-0-p-0-gnu-fontspecific -gnu-lilypond-feta
Re: 3.0 -- gnome backend
[EMAIL PROTECTED] writes: Nicolas Sceaux writes: I have some troubles with it: feta fonts seem not to be found when the gnome output is displayed, although I have done: $ ln -s ~/cvs/lilypond/mf/out ~/.fonts $ mkfontdir ~/.fonts $ xset +fp ~/.fonts Something went wrong here. Does xlsfonts report the feta fonts? Could it be that this is system/distribution specific? -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
