Re: MusicXML and Lilypond, any news?
Hello Omer, This has become a sort of FAQ. Lilypond does not fully support MusicXML and Frescobaldi's support is also experimental. That's due to limited resources of the development team, and because implementing a spectacularly good MusicXML export does not actually benefit the core functionality of Lilypond, which is ,ore important to do at this stage. Export mostly only benefits other programs and user of those programs. That is why this does not have a lot of development. The other comment I would make is that MusicXML has a lot of known limitations and never turned into the global and universal music interchange format that was hoped for, like PDF is for documents. That's because music is vastly more complex that text documents and there is much that it misses out on. I don't think this situation is going to change. You'll find similar threads on the Dorico forum - even the Steinberg development team for that product does not have the resources for MusicXML full support and ongoing development. Sadly a lot of 'big name' publishing houses want MusicXML from composers (and they want the composers to do the work now!), as they don't use Dorico or Lilypond and so on. This is all very unsatisfactory. Not that it answers your question directly, but some people find MuseScore has reasonable MusicXML capabilities. Andrew On 11/10/2022 3:29 am, Omer Katzir wrote: Is there any news about incorporating MusicXML into Lilypond? I need to share my engravings between several people, most aren’t using Lilypond. I know there’s musicxml2ly but I need it the other way around. Thanks in advance for any tips.
Re: 2.23..13 hairpins in brackets
On 10/7/22 17:44, Paul Scott wrote:
Thank you for your answer. It may take me a while to process yours
and the two other answers that I got.
Paul
On 10/6/22 11:06 AM, Jean Abou Samra wrote:
Le 06/10/2022 à 19:31, Paul Scott a écrit :
In 2.23.13 Notation 1.3.1 shows how to mix normal text with dynamic
text.
Is there a way to mix normal text, brackets specifically, with
hairpins? This is used in the U.S. Marine Band versions of the
Sousa marches.
Thank you for any ideas,
Do you mean something like this?
\version "2.23.13"
\markup format-bracket =
\markup \large \vcenter \etc
{
\once \override Parentheses.stencils =
#(lambda (grob)
(list (grob-interpret-markup grob (make-format-bracket-markup
"["))
(grob-interpret-markup grob (make-format-bracket-markup
"]"
\once \override Parentheses.padding = 0.8
c'\parenthesize\<
d' d' c'\!
}
Can I also include a dynamic like mp inside the same bracket?
Thank you,
Paul
Re: 2.23..13 hairpins in brackets
On 10/7/22 17:48, Paul Scott wrote:
Thank you for your answer. It may take me a while to process yours
and the other two answers that I got.
Paul
On 10/6/22 11:19 AM, Xavier Scheuer wrote:
On Thu, 6 Oct 2022 at 19:59, Paul Scott wrote:
>
> In 2.23.13 Notation 1.3.1 shows how to mix normal text with dynamic
text.
>
> Is there a way to mix normal text, brackets specifically, with
> hairpins? This is used in the U.S. Marine Band versions of the Sousa
> marches.
Hello,
Not sure if it corresponds to your request, but it is possible to get
hairpins between brackets by changing the stencil of Parentheses.
#(define-public (bracket-stencils grob)
(let ((lp (grob-interpret-markup grob (markup #:fontsize 3.5
#:translate (cons -0.3 -0.5) "[")))
(rp (grob-interpret-markup grob (markup #:fontsize 3.5
#:translate (cons 0 -0.5) "]"
(list lp rp)))
{
\override Parentheses.stencils = #bracket-stencils
c'1-\parenthesize \< |
c'1\!
}
Cheers,
Xavier
This one doesn't seem to work in 2.23.13 or 2.23.14.
Paul
Re: another 'wrong type argument' error
>> I read that SDK 10.14.1 supports 10.9 as the oldest version (I >> couldn't quickly find the lowest value for SDK 10.15). AFAIK, we >> don't use any functionality that is available on newer macOS >> versions only, so this route seems safe. > > So you checked all of LilyPond's dependencies and can guarantee that > it will stay like this forever? I didn't, and of course I can't give any guaranties. > For the record, the easier variant of this setting is the > environment variable MACOSX_DEPLOYMENT_TARGET. OK. >> Whatever Jonas is able to manage with his build setup, > > I'm not going to work on anything. [...] OK. I agree that without a MacOS developer who has active interest in maintaining support for older versions we cannot follow this path. Werner
Re: another 'wrong type argument' error
On Mon, 2022-10-10 at 05:10 +, Werner LEMBERG wrote: > > Confirmed using otool that the minimum OS for the linked build is > > 10.15: > > > > Load command 10 > > cmd LC_BUILD_VERSION > > cmdsize 32 > > platform 1 > > minos 10.15 > > sdk 10.15.6 > > Thanks. Yes, I build on macOS 10.15 and it will work on versions newer than that, as also announced with the first release of this infrastructure: https://lists.gnu.org/archive/html/lilypond-user/2022-02/msg00155.html > > That is certain to be the reason why it doesn’t run, but I suspect > > a local build might run fine. I’d suggest setting this lower for > > binary releases if there’s no pressing reason to require 10.15 on > > Mac. > > Sounds sensible. Jonas? I don't agree; I chose macOS 10.15 as a target because it was, until recently, the oldest supported version. If we try to lower this requirement I have no idea what will be work, and even worse I don't have the possibility to test it. FWIW Homebrew also only actively supports macOS 10.15, everything below that is provided on a best- effort basis (and may be broken to a certain degree). > On page > > https://smallhacks.wordpress.com/2018/11/11/how-to-support-old-osx-version-with-a-recent-xcode/ > > I read that SDK 10.14.1 supports 10.9 as the oldest version (I > couldn't quickly find the lowest value for SDK 10.15). AFAIK, we > don't use any functionality that is available on newer macOS versions > only, so this route seems safe. So you checked all of LilyPond's dependencies and can guarantee that it will stay like this forever? > > For reference when using clang/llvm the relevant compiler flag to > > set the deployment target is: > > > > -mmacos-version-min= > > BTW, this flag is necessary for both compiling and linking. For the record, the easier variant of this setting is the environment variable MACOSX_DEPLOYMENT_TARGET. > Whatever Jonas is able to manage with his build setup, I'm not going to work on anything. I have been alone trying to get a build for macOS even though I don't even use Apple hardware and other core developers do. It will take somebody willing to work on this effort *and commit to maintaining it* because I don't think it's a good idea to release something half-working. > I suggest to add a note to the download section(s) like the > following: > > The macOS x86_64 binary works with macOS X.Y and higher. For older > macOS versions please use MacPorts. Yes, we can do that once we have the stable release and the binaries are available from the Downloads page, it's generally not written on the Development page. Jonas signature.asc Description: This is a digitally signed message part
Re: another 'wrong type argument' error
On Mon, 2022-10-10 at 08:08 +0200, Jean Abou Samra wrote: > > > Le 9 oct. 2022 à 22:45, Kieren MacMillan a > > écrit : > > > > dyld: 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 > > Abort trap: 6 > > What surprises me in this error message is that mentions a dynamic library > in /opt/local/lib, which I read is for MacPorts, but I thought we were > linking with dependencies like libiconv statically. Where am I going wrong > in my thinking? We are only building libiconv for Windows; on the other platforms (Linux, macOS, and also FreeBSD) it's provided by the system. On Linux it's included in glibc and on macOS (at least on version 10.15) there is /usr/lib/libiconv.2.dylib which apparently MacPorts replaces with their own version. I'm not sure though at what point libcups.2.dylib come in... Jonas signature.asc Description: This is a digitally signed message part
Re: another 'wrong type argument' error
Hi Jean,
> This looks like you have done something like
> { c'\custdyn "p" }
> instead of
> { c'\custdyn "{p}" }
Hmmm… the only three calls I have look like the second (correct) version, not
the first. But switching those three custom dynamics to simple/native dynamics
eliminates the error, so it's definitely something in that code that's breaking.
Because I need to keep ploughing forward on this score, I'm going to bail here
and just leave them as simple dynamics… When I can take a breath (next week?),
I'll return and see if I/we can figure out the real root of the problem.
Thank you so much for all your help!
Kieren.
Re: another 'wrong type argument' error
Le 10/10/2022 à 19:07, Kieren MacMillan a écrit :
Hi Jean,
Can you send the complete code? It seems to be missing
the function dynamic-text::structered-list.
I've attached the include file I use.
Thanks!
Kieren.
This looks like you have done something like
{ c'\custdyn "p" }
instead of
{ c'\custdyn "{p}" }
The code tries to center the first (by default) dynamic
(i.e., "{...}") part encountered in the custom dynamic
text under the note. If there is no dynamic part, this
doesn't work.
Cheers,
Jean
Re: another 'wrong type argument' error
Hi Jean, > Can you send the complete code? It seems to be missing > the function dynamic-text::structered-list. I've attached the include file I use. Thanks! Kieren. dynamics_on-the-fly.ly Description: Binary data
Re: another 'wrong type argument' error
Hi Jean, > Re screenshot: what editor are you using? > > In Frescobaldi, it seems that there is a glitch that prevents from > pasting from the log output if you have selected something at the same > time in the LilyPond code view, because that takes priority apparently, > but in my experience, if you stop selecting something in the code, > copy-pasting from the log works just fine. FYI: That worked. Thanks! Kieren.
Re: another 'wrong type argument' error
p.s. > Looking at dynamics_on-the-fly.ly, line 294+ is > > (if (pair? prev-self-alignment-X-tweaks) > '() > (ly:grob-set-property! grob 'X-offset > (let* ((x-exts > (map >(lambda (stil) (ly:stencil-extent stil X)) >(take all-stils 2))) >(x-par (ly:grob-parent grob X)) >(parent-x-ext-center > (interval-center >(if (ly:grob-property grob > 'X-align-on-main-noteheads) >(note-column::main-extent x-par) >(ly:grob-extent x-par x-par X > > with line 300 being > >(take all-stils 2))) > > What's the patch? Looks like the definition [earlier in the code] is (all-stils (map (lambda (mrkp) (if (null? mrkp) empty-stencil (grob-interpret-markup grob (if (markup-list? mrkp) (make-concat-markup mrkp) mrkp stil-candidates)) In case that helps…? Thanks, Kieren.
Re: another 'wrong type argument' error
Le 10/10/2022 à 18:56, Kieren MacMillan a écrit : Hi Jean (et al.), Heh, 2.23.14 _just_ came out. MacPorts got updated. I upgraded. Good news! The maintainer is pretty reactive. try using that and putting #(ly:set-option 'compile-scheme-code) at the top of your file (before any includes). Also add #(debug-enable 'backtrace) for best results. Done. Result: [...] Can you send the complete code? It seems to be missing the function dynamic-text::structered-list.
Re: another 'wrong type argument' error
Hi Jean (et al.), > Heh, 2.23.14 _just_ came out. MacPorts got updated. I upgraded. > try using that and putting #(ly:set-option 'compile-scheme-code) at the top > of your file (before any includes). > Also add #(debug-enable 'backtrace) for best results. Done. Result: Preprocessing graphical objects...Backtrace: 9 (apply-smob/1 #) In /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond-devel/work/lilypond-2.23.14/out/share/lilypond/current/scm/lily/lily.scm: 876:16 8 (lilypond-main _) 905:4 7 (lilypond-all _) In srfi/srfi-1.scm: 640:9 6 (for-each # ?) In /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond-devel/work/lilypond-2.23.14/out/share/lilypond/current/scm/lily/lily.scm: 915:9 5 (_ _) In ice-9/boot-9.scm: 829:9 4 (catch _ _ # ?) In unknown file: 3 (ly:parse-file "/Users/kmac/Documents/01_music/scores/3?") 2 (ly:book-process # #< Output_def> #< Output_def> #) In /Users/kmac/Documents/01_music/scores/_include/init/Workarounds/dynamics_on-the-fly.ly: 300:32 1 (tweak-proc #) In unknown file: 0 (list-head () 2) Looking at dynamics_on-the-fly.ly, line 294+ is (if (pair? prev-self-alignment-X-tweaks) '() (ly:grob-set-property! grob 'X-offset (let* ((x-exts (map (lambda (stil) (ly:stencil-extent stil X)) (take all-stils 2))) (x-par (ly:grob-parent grob X)) (parent-x-ext-center (interval-center (if (ly:grob-property grob 'X-align-on-main-noteheads) (note-column::main-extent x-par) (ly:grob-extent x-par x-par X with line 300 being (take all-stils 2))) What's the patch? Thanks! Kieren.
Re: MusicXML and Lilypond, any news?
Le 10/10/2022 à 18:29, Omer Katzir a écrit : Is there any news about incorporating MusicXML into Lilypond? I need to share my engravings between several people, most aren’t using Lilypond. I know there’s musicxml2ly but I need it the other way around. Thanks in advance for any tips. The latest thread about this was not very long ago, you could start by reading this. https://lists.gnu.org/archive/html/lilypond-user/2022-10/msg00014.html Best, Jean
MusicXML and Lilypond, any news?
Is there any news about incorporating MusicXML into Lilypond? I need to share my engravings between several people, most aren’t using Lilypond. I know there’s musicxml2ly but I need it the other way around. Thanks in advance for any tips.
Re: another 'wrong type argument' error
Hi all, > one cannot expect bleeding-edge software to run on unsupported OSes For sure… I guess I just never thought of Lilypond as "bleeding-edge" before! :) > My point was to > temper the movement to investigate technical details of supporting > old macOS and remind that it is already painful enough for us to > support current OSes and architectures. I don't want any real development bandwidth spent on this issue: If it's a matter of just setting a 'minos' parameter and everything works perfectly, then great — if it's more than that, or if lowering the minos breaks something else, then the dev-pool shouldn't pursue it further. > PS: my offer to look at the file if provided with it still stands. I appreciate the offer, and will try to send you something the moment I have the chance. (Right now, I'm scrambling to get other scores composed, arranged, input, and compiled — rehearsals start on Wednesday!) Thanks (all!) for your help. Kieren.
Re: another 'wrong type argument' error
Le 10/10/2022 à 13:06, Wols Lists a écrit : On 10/10/2022 06:43, Jean Abou Samra wrote: The problem isn’t LilyPond’s or its dependencies’ support for older macOS, which is better than even the system support. The real problem is Apple preventing you from upgrading your computer past a certain macOS version. Which is probably down to newer versions of MacOS taking advantage of new chip features. Linux drops support for older chips over time - it's almost impossible to get a distro that supports plain x86 any more ... Because Apple has far tighter integration between computer and OS, they can more easily upgrade in lock-step. Well, it is also a part of their business model. At any rate, I don't necessarily want to judge the merits of an OS/company, but to explain that one cannot expect bleeding-edge software to run on unsupported OSes. When you buy Apple hardware, you know upfront what to expect with respect to upgrades. My point was to temper the movement to investigate technical details of supporting old macOS and remind that it is already painful enough for us to support current OSes and architectures. It is a perfectly reasonable solution to hope some people with actual hardware running old macOS versions and with expertise in macOS to produce adequate binaries, like MacPorts should be doing shortly. So is running a system that is supported, and there are many GNU/Linux distros out there that can be installed on such hardware at no cost. Best, Jean PS: my offer to look at the file if provided with it still stands.
Re: another 'wrong type argument' error
Wols Lists writes: > On 10/10/2022 06:43, Jean Abou Samra wrote: >> The problem isn’t LilyPond’s or its dependencies’ support for older >> macOS, which is better than even the system support. The real >> problem is Apple preventing you from upgrading your computer past a >> certain macOS version. > > Which is probably down to newer versions of MacOS taking advantage of > new chip features. > > Linux drops support for older chips over time - it's almost impossible > to get a distro that supports plain x86 any more Which would be what? 30 years? My current computer is about 10 years, the backup computer about 15 years old. Both are running current GNU/Linux systems. I think it was about 5 years ago that EISA bus support was removed. > ... Because Apple has far tighter integration between computer and OS, > they can more easily upgrade in lock-step. Removing old hardware support is not mandatory. Admittedly that does not really hold when migrating to a completely different CPU architecture, and Apple affords that move roughly every one or two decades (Motorola 68K to PowerPC to x86 to M1 if I remember correctly with regard to macOS), -- David Kastrup
Re: another 'wrong type argument' error
On 10/10/2022 06:43, Jean Abou Samra wrote: The problem isn’t LilyPond’s or its dependencies’ support for older macOS, which is better than even the system support. The real problem is Apple preventing you from upgrading your computer past a certain macOS version. Which is probably down to newer versions of MacOS taking advantage of new chip features. Linux drops support for older chips over time - it's almost impossible to get a distro that supports plain x86 any more ... Because Apple has far tighter integration between computer and OS, they can more easily upgrade in lock-step. Cheers, Wol
Re: another 'wrong type argument' error
>> That is certain to be the reason why it doesn’t run, but I suspect >> a local build might run fine. I’d suggest setting this lower for >> binary releases if there’s no pressing reason to require 10.15 on >> Mac. > > Sounds sensible. Jonas? And thanks for having done the release, Jonas! Werner
Re: another 'wrong type argument' error
> Le 9 oct. 2022 à 22:45, Kieren MacMillan a > écrit : > > dyld: 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 > Abort trap: 6 What surprises me in this error message is that mentions a dynamic library in /opt/local/lib, which I read is for MacPorts, but I thought we were linking with dependencies like libiconv statically. Where am I going wrong in my thinking?
