Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
Il giorno ven 6 ott 2017 alle 21:25, Karlin High ha scritto: On Thu, Oct 5, 2017 at 7:01 AM, Federico Bruni wrote: Anyway, if we decide that the setup script in LilyDev should include your proposal, I'll be happy to see a pull request https://github.com/fedelibre/LilyDev/pull/8 If you decide against including this, I will be OK with that. Perhaps 5 or so :) new contributors might benefit before the fonts get included in the LilyDev base distro and this issue self-resolves. -- Thank you Karlin, I've started having a look at it, but I don't have much spare time these days... The main problem with LilyDev master (version 5) is that it's meant for guile-2 migration (which seems stopped), but I guess that most of contributors are not interested in this and want to be able to build lilypond on master branch. So this is the main issue to fix in LilyDev. Or maybe I should just move to LilyDevOS and forget LilyDev. It would be much easier for me. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
On Tue, Oct 10, 2017 at 6:09 AM, Federico Bruni wrote: > Thank you Karlin, I've started having a look at it, but I don't have much > spare time these days... > The main problem with LilyDev master (version 5) is that it's meant for > guile-2 migration (which seems stopped), but I guess that most of > contributors are not interested in this and want to be able to build > lilypond on master branch. So this is the main issue to fix in LilyDev. How deep of an understanding of guile and LilyPond internals does someone need to work on guile-2 migration? I am under the impression that with anything much below David Kastrup's, it is largely out of the question. For LilyDev, there are also other complaints from the configure script. I saw something from libpango, GhostScript, extractpdfmark, and possibly more. Reporting the details of these is on my LilyPond to-do list. I was able to resolve the GhostScript issue by cloning the git repository, doing a checkout on the tag for version 9.20, and compiling from source. The other packages have further dependencies, and I didn't follow the rabbit holes to their ends. > Or maybe I should just move to LilyDevOS and forget LilyDev. It would be > much easier for me. And I can mostly make LilyDevOS work for me. But I'm a Debian native, and the Fedora environment stumbles me sometimes. And THEN there's going to be issues with the lily-git.tcl script; for the life of me I couldn't get it connected from the terminal window to my X display, even after further research on the instructions for it. The setup I had involved XRDP for remote access, so I am blaming that. I once saw a list discussion somewhere about replacing this TCL script, as it was the only thing in the entire project using the language. And then I saw a - perhaps a GitHub project? - for a dialog.sh script that aimed to have functionality like ncurses for having a user interface right in a command-line terminal. -- Karlin High Missouri, USA ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: \tempo feature requests
Hi list, I made a patch for this (only snippet 1008, not yet 574). Because that’s not a bugfix but an extension to LilyPond, should this first be discussed on this list or on the issue tracker? Or should I upload it right now to Rietveld and discuss then? Cheers, Malte Weitergeleitete Nachricht Betreff: \tempo feature requests Datum: Mon, 9 Oct 2017 11:44:44 +0200 Von: Malte Meyn An: bug-lilypond Hi list, could the snippets http://lsr.di.unimi.it/LSR/Item?id=1008 and http://lsr.di.unimi.it/LSR/Item?id=574 become part of LilyPond? Maybe with all or some of the following additions/changes: Snippet 1008: • To make it backwards-compatible don’t change the default sizes; maybe introduce a grob property which scales the notes. • IMO coloring (only) the number is very special and could be omitted. • Offer three values for tempoShowParentheses: #t, #f and 'if-no-text (the latter mimicking the current default behaviour). • Add ASCII/scheme symbol shorthands for non-ASCII symbols like ≈ and ≙. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: \tempo feature requests
On 10.10.2017 13:57, Malte Meyn wrote: I made a patch for this (only snippet 1008, not yet 574). Because that’s not a bugfix but an extension to LilyPond, should this first be discussed on this list or on the issue tracker? Or should I upload it right now to Rietveld and discuss then? Especially if you already made a patch, uploading for review is the most promising route, I think. Everything else is likely to take much longer time and narrow down the chances for effective results… Best, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
Karlin High writes: > On Tue, Oct 10, 2017 at 6:09 AM, Federico Bruni wrote: >> Thank you Karlin, I've started having a look at it, but I don't have >> much spare time these days... The main problem with LilyDev master >> (version 5) is that it's meant for guile-2 migration (which seems >> stopped), but I guess that most of contributors are not interested in >> this and want to be able to build lilypond on master branch. So this >> is the main issue to fix in LilyDev. > > How deep of an understanding of guile and LilyPond internals does > someone need to work on guile-2 migration? I am under the impression > that with anything much below David Kastrup's, it is largely out of > the question. Not all that much until you hit a roadblock. Then you yell. The current roadblocks tend to be of the kind that is little related to LilyPond internals and a lot related to Guile and C and C++. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
Il giorno mar 10 ott 2017 alle 13:52, Karlin High ha scritto: On Tue, Oct 10, 2017 at 6:09 AM, Federico Bruni wrote: Thank you Karlin, I've started having a look at it, but I don't have much spare time these days... The main problem with LilyDev master (version 5) is that it's meant for guile-2 migration (which seems stopped), but I guess that most of contributors are not interested in this and want to be able to build lilypond on master branch. So this is the main issue to fix in LilyDev. For LilyDev, there are also other complaints from the configure script. I saw something from libpango, GhostScript, extractpdfmark, and possibly more. Reporting the details of these is on my LilyPond to-do list. I was able to resolve the GhostScript issue by cloning the git repository, doing a checkout on the tag for version 9.20, and compiling from source. The other packages have further dependencies, and I didn't follow the rabbit holes to their ends. extractpdfmark is available on debian stretch, see: https://packages.debian.org/stretch/extractpdfmark https://github.com/trueroad/extractpdfmark It's not available in Fedora, unfortunately. tlmgr is not available in Fedora either. So I compiled extractpdf from source. Or maybe I should just move to LilyDevOS and forget LilyDev. It would be much easier for me. And I can mostly make LilyDevOS work for me. But I'm a Debian native, and the Fedora environment stumbles me sometimes. I was already thinking about adding a Debian container. It will be pretty quick. The only problem is guile-1.8: I guess I'll have to pin it from sid. So it would be: a fedora container, a debian container and a full virtual machine running Fedora with LXQT desktop. And THEN there's going to be issues with the lily-git.tcl script; for the life of me I couldn't get it connected from the terminal window to my X display, even after further research on the instructions for it. The setup I had involved XRDP for remote access, so I am blaming that. I never used lily-git.tcl so I totally forgot about it. In the container try updating your .bashrc this way (I've added auxiliar to the path and an alias for lily-git): $ tail ~/.bashrc # Add other directories to the PATH export PATH=$HOME/git-cl:$LILYPOND_GIT/scripts/auxiliar:$PATH # Let some GUI programs work on host display alias gitk="DISPLAY=:0 gitk" alias lily-git.tcl="DISPLAY=:0 lily-git.tcl" I will add these changes in next release. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
make metronomeMarkFormatter more flexible (issue 327620043 by lilyp...@maltemeyn.de)
I think this approach is a rather bad tradeoff between additional
context properties and actual flexibility: it still only allows for a
very limited subset of metronome marks.
I think it would make sense to check all forms a \tempo mark currently
can take and then see what principal forms those can assume. Then, one
needs to look how many basically different format functions it makes
sense to specify for those forms and pass those the _raw_ information in
the \tempo mark, making them responsible for proper formatting.
That's for formatting: probably something needs to be there in parallel
for calculating the moments-per-minute value.
Maybe we want something like
\tempo { \tuplet 2/3 { 4 8 } } = 45
to work as well? That would require yet another hook.
https://codereview.appspot.com/327620043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make metronomeMarkFormatter more flexible (issue 327620043 by lilyp...@maltemeyn.de)
Reviewers: dak,
Message:
On 2017/10/10 16:29:05, dak wrote:
I think this approach is a rather bad tradeoff between additional
context
properties and actual flexibility: it still only allows for a very
limited
subset of metronome marks.
That’s true. BTW, I don’t even know why tempoHideNote and the properties
of this snippet and patch are context properties and not properties of
MetronomeMark.
I think it would make sense to check all forms a \tempo mark currently
can take
and then see what principal forms those can assume.
Something like that?
\tempo "Allegro" → Allegro
\tempo 4 = 120 → 𝅘𝅥 = 120
\tempo "Allegro" 4 = 120 → Allegro (𝅘𝅥 = 120)
\tempo 4 = 120-132 → 𝅘𝅥 = 120 – 132
\tempo "Allegro" 4 = 120-132 → Allegro (𝅘𝅥 = 120 – 132)
\tempo "" 4 = 120→ (𝅘𝅥 = 120) [misaligned]
\tempo "" 4 = 120-132→ (𝅘𝅥 = 120 – 132) [misaligned]
I’m not sure what you mean by “principal forms”. Could you explain? I
made a list of limitations that the metronome mark formatter currently
has:
• font
– size
∘ everything can be scaled by grob property font-size
∘ text can then be scaled independently by markup commands
∘ note/numbers cannot be scaled independently
– series
∘ numbers can be made bold by grob property font-series
∘ text doesn’t respect the grob property, can be made medium by
markup command
• brackets
– type
∘ only round brackets
– presence
∘ present if text is set
∘ text but no brackets: impossible
∘ no text but brackets: possible but misaligned because of leading
space
• note
– stem
∘ only up
– duration
∘ only one note, no ties
∘ only simple durations, no tuplets
• number
– type
∘ only integer (floating point is not nice to print as pointed out
on the user list some time ago but rationals might be wanted)
– range
∘ dash is hardcoded (endash surrounded by thin spaces)
• equation
– equation sign
∘ sign is hardcoded (= surrounded by spaces), so neither other signs
like ≈ or ≥ nor text like “= approx.” are possible
– type
∘ only “note = number”/“note = range”, not “note = note”
• miscellani
– swing feeling
∘ not really a tempo indication, but 8 8 = \tuplet 3/2 { 4 3 } and
others would be nice (see equation→type and note→duration)
Then, one needs to look how
many basically different format functions it makes sense to specify
for those
forms and pass those the _raw_ information in the \tempo mark, making
them
responsible for proper formatting.
So you don’t want grob and context properties for the fine tuning but
different functions? That sound like an awful lot of functions to me
(similar to the rehearsal mark formatters).
That's for formatting: probably something needs to be there in
parallel for
calculating the moments-per-minute value.
Yes, that would be nice.
Maybe we want something like
\tempo { \tuplet 2/3 { 4 8 } } = 45
to work as well? That would require yet another hook.
What is this supposed to mean/look like? Does it mean \tempo 4 = 45 or
\tempo 4*2/3 = 45? Should this output one quarter note or two notes?
Description:
make metronomeMarkFormatter more flexible
This adds the context properties tempoEquationText, tempoBetweenText and
tempoShowParentheses as shown in http://lsr.di.unimi.it/LSR/Item?id=1008
It also allows to scale the size of the notes in a metronome mark
independently from or rather relatively to the text and numbers.
I added this possibility because http://lsr.di.unimi.it/LSR/Item?id=1008
suggests smaller note sizes; so there seems to be a need for that.
The default values are chosen so that the whole thing is backwards
compatible; to achieve this, tempoShowParentheses accepts not only
boolean values but also the symbol 'if-text.
I chose the name tempoShowParentheses instead of tempoHideParentheses
because this property also allows parenthesizing text-less
MetronomeMarks.
Contains regtests.
Please review this at https://codereview.appspot.com/327620043/
Affected files (+94, -16 lines):
A input/regression/metronome-mark-formatter-extended.ly
A input/regression/metronome-mark-note-size.ly
M lily/metronome-engraver.cc
M scm/define-context-properties.scm
M scm/translation-functions.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
2017-10-10 15:25 GMT+02:00 David Kastrup : > Karlin High writes: > >> On Tue, Oct 10, 2017 at 6:09 AM, Federico Bruni wrote: >>> Thank you Karlin, I've started having a look at it, but I don't have >>> much spare time these days... The main problem with LilyDev master >>> (version 5) is that it's meant for guile-2 migration (which seems >>> stopped), but I guess that most of contributors are not interested in >>> this and want to be able to build lilypond on master branch. So this >>> is the main issue to fix in LilyDev. >> >> How deep of an understanding of guile and LilyPond internals does >> someone need to work on guile-2 migration? I am under the impression >> that with anything much below David Kastrup's, it is largely out of >> the question. > > Not all that much until you hit a roadblock. Then you yell. The > current roadblocks tend to be of the kind that is little related to > LilyPond internals and a lot related to Guile and C and C++. > > -- > David Kastrup Some time ago Antonio worked on it, see https://ao2.it/tmp/lilypond-guile2/ https://ao2.it/tmp/lilypond-guile2/TODO Some patches (but slightly different) are now in master, all in dev/guile-v2-work (you'd need to rebase dev/guile-v2-work and solve some merge-conflicts, if you'd try to build from this branch) My plan was to put all of his patches into master with if-guilev2-conditions. Though, it was the agreement not to go for guile2 for lilypond-2.20.0, so I didn't continue, because I didn't want to disturb the 2.20.-release or distracting from it. Also, it's the question which guile-version we should aim at. Antonio's patches are made for guile-2.0, but guile-2.2 is far more promising, imho. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
Am 10.10.2017 um 20:56 schrieb Thomas Morley: Also, it's the question which guile-version we should aim at. Antonio's patches are made for guile-2.0, but guile-2.2 is far more promising, imho. About a year ago guile 2.0 was terribly slow. Is there any progress? Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
Knut Petersen writes: > Am 10.10.2017 um 20:56 schrieb Thomas Morley: >> Also, it's the question which guile-version we should aim at. >> Antonio's patches are made for guile-2.0, but guile-2.2 is far more >> promising, imho. > > About a year ago guile 2.0 was terribly slow. Is there any progress? Respective to 2.0, yes. But it's still decidedly awful compared to 1.8 as used in LilyPond. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?
2017-10-10 22:53 GMT+02:00 David Kastrup : > Knut Petersen writes: > >> Am 10.10.2017 um 20:56 schrieb Thomas Morley: >>> Also, it's the question which guile-version we should aim at. >>> Antonio's patches are made for guile-2.0, but guile-2.2 is far more >>> promising, imho. >> >> About a year ago guile 2.0 was terribly slow. Is there any progress? > > Respective to 2.0, yes. But it's still decidedly awful compared to 1.8 > as used in LilyPond. > > -- > David Kastrup 2.2 is faster than 2.0 but still much slower than 1.8. This may improve, if we manage to get reasonable use of .go-files. In my experience 2.2 eats far less memory even compared to 1.8. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
