Re: compiling MacOS application in LilyDev
Hi Hans, > You tried what? Making your own installer from MacPorts? I tried port install lilypond-devel > I can post the steps I use to make the installer if you so want. I would appreciate that. Thanks! Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: TimeSignature with note in denominator
Hi,
BTW, Gould gives the following example in her book (also noting that
it would be better to use 15/16 together with a '2+3 sempre' remark
instead).
3
--
8 ~ 8.
(the tilde denotes a tie).
Sorry if I miss the point completely (I only skimmed part of the e-mail
thread).
This reminds me of the \rhythm markup function that David K. once
suggested (if I recall it correctly); the version I'm currently using is:
\version "2.23.4"
#(define-markup-command (rhythm layout props content) (ly:music?)
#:properties ((time #f))
(interpret-markup layout props #{
\markup {
\score {
\new RhythmicStaff \with {
\override StaffSymbol.line-count = 0
\override Rest.staff-position = 2
\override BarLine.bar-extent = #'(-0.5 . 2)
\override TimeSignature.Y-offset = 0.5
#(if (not time)
#{ \with {
\remove Time_signature_engraver
} #})
}
{
#(if time #{ \time $time #})
#content
}
\layout {
indent = 0
#(layout-set-staff-size 12)
}
}
} #}))
\markup \rhythm { 8 ~ 8. }
This could be used for a \time variant:
wernerTime =
#(define-music-function (num den) (positive? ly:music?)
#{
\override Timing.TimeSignature.stencil =
#(lambda (grob)
(grob-interpret-markup
grob
#{
\markup \override #'(baseline-skip . 0) \center-column {
\number #(number->string num)
\rhythm { \voiceTwo #den }
}
#}))
\time 4/4 % of course that's crazy
\set Timing.measureLength =
#(ly:moment-mul
(ly:music-length den)
(ly:make-moment num))
#})
{
\wernerTime 3 { 8 ~ 8. }
\repeat unfold 15 c'16
\wernerTime 1 { 8. }
\repeat unfold 9 c'16
}
Of course there's a lot of work undone - in particular, constructing a
beat structure out of the given rhythm.
Lukas
Re: compiling MacOS application in LilyDev
> On 9 Nov 2021, at 19:06, Kieren MacMillan > wrote: > > Hi Hans, > >> One can make installers with MacPorts, I posted some on the users list. > > I found that thread — helpful! > > I tried, and got: > > Error: … You tried what? Making your own installer from MacPorts? —The ones I do install in /opt/lilypond/, and you use /opt/lilypond/ it looked like. The location I use is suggested by the FHS (file hierarchy standard) and Werner. One issue is that /opt/lilypond/bin/ must be in PATH, otherwise some programs like 'gs' will not be called. I can post the steps I use to make the installer if you so want. It might be of interest if you try making a universal installer, but it would likely involve getting touch with the MacPorts people for help.
Re: compiling MacOS application in LilyDev
Hi Hans,
> The intent is probably to create an app.
Yes, for me to run (personally).
> One can make installers with MacPorts, I posted some on the users list.
I found that thread — helpful!
I tried, and got:
Error: Failed to activate dbus: Image error:
/Library/LaunchAgents/org.freedesktop.dbus-session.plist already exists and
does not belong to a registered port. Unable to activate port dbus. Use 'port
-f activate dbus' to force the activation.
I tried that, and got
dlopen(/opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib, 6): Symbol
not found: _iconv
Referenced from: /usr/lib/libcups.2.dylib
Expected in: /opt/local/lib/libiconv.2.dylib
in /usr/lib/libcups.2.dylib
while executing
"load /opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib"
("package ifneeded macports 1.0" script)
invoked from within
"package require macports"
(file "/opt/local/bin/port" line 46)
Advice?
Thanks,
Kieren.
Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info
Re: TimeSignature with note in denominator
Kieren MacMillan writes: > Hi Jean, > >> Correct me if I'm wrong, but I am under >> the impression that the semantics of this >> new feature should be quite different >> from the usual \time. > > I don’t know about "*quite* different"… but possibly *somewhat* different. > >> We usually interpret >> 6/8 as (4. + 4.) because (4 + 4 + 4) has >> the representation 3/4. If you write 6 >> over an eight note, you're not meaning >> (4. + 4.) because you could have written >> that as 2 over a dotted quarter note. >> So you really mean (8 + 8 + 8 + 8 + 8 + 8). >> Correct? > > I suppose that’s one way to frame it. But isn’t that just > > \time #'(1 1 1 1 1 1) 6/8 > > ? i.e., are the semantics of the feature different before or after the > user interface layer? > > Same, TBH, with \compoundMeter: In a perfect world, wouldn’t we want > the option to write > >\time #'((3 . 4) (3 . 8)) > > instead of having a whole separate function? Why *wouldn’t* we want a > \time function that handles all possible time signatures? Why _would_ we want it? If it becomes impossible to see what the author actually wants because there is so much overlap in how the arguments could be interpreted, where is the advantage? This is just "I want the computer to typeset what I mean, not what I say". But that's not just confusing to computers. -- David Kastrup
Re: Manipulating instrument names and staff group names
Hi Jean, > 3. I believe you are a bit quick in believing you >will never, ever be able to write C++ code ;-) I didn’t say I wouldn’t be *able* to write C++ code… I said > but very little chance of ever C++-ing ;-) My prediction was more about my likely enthusiasm and commitment than my ability (or lack thereof). Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: TimeSignature with note in denominator
Hi Jean, > Correct me if I'm wrong, but I am under > the impression that the semantics of this > new feature should be quite different > from the usual \time. I don’t know about "*quite* different"… but possibly *somewhat* different. > We usually interpret > 6/8 as (4. + 4.) because (4 + 4 + 4) has > the representation 3/4. If you write 6 > over an eight note, you're not meaning > (4. + 4.) because you could have written > that as 2 over a dotted quarter note. > So you really mean (8 + 8 + 8 + 8 + 8 + 8). > Correct? I suppose that’s one way to frame it. But isn’t that just \time #'(1 1 1 1 1 1) 6/8 ? i.e., are the semantics of the feature different before or after the user interface layer? Same, TBH, with \compoundMeter: In a perfect world, wouldn’t we want the option to write \time #'((3 . 4) (3 . 8)) instead of having a whole separate function? Why *wouldn’t* we want a \time function that handles all possible time signatures? Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: Manipulating instrument names and staff group names
Le 08/11/2021 à 21:13, Jonas Hahnfeld via Discussions on LilyPond development a écrit : Am Sonntag, dem 07.11.2021 um 15:59 -0500 schrieb Kieren MacMillan: Hi Jonas, "Defect" is for problems within the "core program", which means either C++ or Scheme. I would argue that those two are not really separable in most cases Does that mean for someone like me — with a fighting chance of Scheme-ing, but very little chance of ever C++-ing — there are very few [non-documentation] issues I can likely fix? Not necessarily, let me elaborate what I had in mind when I wrote the above; for the record, I'm referring to issues as reports from users saying that something crashes / broke / isn't working as expected. For those issues, I think a fair amount will actually require C++ knowledge; if not for fixing, then at least for understanding how many of the internals are working and how Scheme fits in. This is not to say that there are none that are entirely solvable in Scheme, but that it will be hard to stamp them as such without going 80% of the way to solve them. The story may be a bit different for new features where it's about adding new code. My 2 cents, others might disagree. I agree. I would add that 1. It's hard to see if a random issue taken out of the 1000 will require C++ or not, but it's not hard to find a few in all that meeting this criterion; 2. Tracker issues are an aid for us, not an ultimate goal; there is a lot that you can do to improve Scheme and pure-LilyPond code (features, but also interfaces, quality, architecture, etc.); 3. I believe you are a bit quick in believing you will never, ever be able to write C++ code ;-) Best, Jean
Re: TimeSignature with note in denominator
Le 08/11/2021 à 22:09, Kieren MacMillan a écrit : h… Thinking about it a little more, I realize that (a) there really isn’t a backwards compatibility issue *unless* I change \time itself; and (2) as long as \timeII outputs TimeSignatureMusic, “stylesheets” will still apply fine across all TimeSignatures [regardless of what function creates them]. So: In your opinion, would adding a new function be superior overall to “improving” the existing \time function? Correct me if I'm wrong, but I am under the impression that the semantics of this new feature should be quite different from the usual \time. We usually interpret 6/8 as (4. + 4.) because (4 + 4 + 4) has the representation 3/4. If you write 6 over an eight note, you're not meaning (4. + 4.) because you could have written that as 2 over a dotted quarter note. So you really mean (8 + 8 + 8 + 8 + 8 + 8). Correct? If so, that's not only good reason but also necessity for a new function. Cheers, Jean
Re: strange bbox of 'flat' glyph
Le 09/11/2021 à 10:18, Han-Wen Nienhuys a écrit : my worry would be alignment of accidental clusters. If you tweak vertical sizes, can you still have accidentals at an octave distance without colliding? The accidental placement algorithm is based on the glyphs' horizontal skylines, not their simple extents. Jean
Re: compiling MacOS application in LilyDev
> On 9 Nov 2021, at 00:50, Karlin High wrote: > > On 11/8/2021 4:55 PM, Kieren MacMillan wrote: >> I’m on 10.13.6 (High Sierra) > > High Sierra can still run 32-bit, right? That could allow for using GUB on > LilyDev to produce a standard macOS installer. The intent is probably to create an app. One can make installers with MacPorts, I posted some on the users list. They are for a specific MacOS version. One can also make universal installers, but some component did not compile when I tried. Also, LilyPond can overflow on 32-bit: some issue resolved when I switched to the MacPorts version which is 64-bit. So only use the 32-bit version if 64-bit is not available, I think.
Re: strange bbox of 'flat' glyph
On Mon, Nov 8, 2021 at 7:30 PM Werner LEMBERG wrote: > >> Does anybody know why the top and the bottom of the bounding box of > >> the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide > >> (more or less) with the extrema of the glyph's outline? A small > > > > I can't remember any reason. > > :-) > > The question is whether we should fix this. > > Given that such a change would only affect markups where you access > the glyph with `\flat` or something similar (that is, the markup is > handled by Pango, and we won't change the horizontal advance width), > the risk of unwanted effects like text reflow is quite low IMHO. my worry would be alignment of accidental clusters. If you tweak vertical sizes, can you still have accidentals at an octave distance without colliding? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: strange bbox of 'flat' glyph
On 08.11.2021 18:30, Werner LEMBERG wrote: Does anybody know why the top and the bottom of the bounding box of the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide (more or less) with the extrema of the glyph's outline? A small I can't remember any reason. The question is whether we should fix this. Given that such a change would only affect markups where you access the glyph with `\flat` or something similar (that is, the markup is handled by Pango, and we won't change the horizontal advance width), the risk of unwanted effects like text reflow is quite low IMHO. Werner -- I created https://gitlab.com/lilypond/lilypond/-/issues/6208 anyway so that we don't 'discover' this all over again in a few years time. Regards James
PATCHES - Countdown for November 9th
Hello, Here is the current patch countdown list. The next countdown will be on November 11th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !986 release: don't modify our own environment - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/986 Countdown: !996 Fix \volta ... \set ... creating unexpected Staff - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/996 !995 Correct Smob names in "Wrong type" error messages - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/995 !994 Fixed tests in python/musexpr.py - Timofey https://gitlab.com/lilypond/lilypond/-/merge_requests/994 !993 mf: some debugging improvements - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/993 !992 Doc: insignificant follow-ups to “Various doc issues” (!872) - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/992 !990 Forbid C-style casts - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/990 !989 Fix \tuplet ... \set ... creating unexpected Staff - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/989 !897 support cairo backend in lilypond-book - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/897 Review: No patches in Review at this time. New: No patches in New at this time. Waiting: !913 release: binaries with cairo - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/913 *** -- Regards James OpenPGP_0xAAC8D177A7F5A364.asc Description: application/pgp-keys
