Re: bookOutputName still gets "-1" suffix added to SVG file names
On 3/30/2023 7:05 PM, Jean Abou Samra wrote:
I don't understand the problem you're having. Is my suggestion of
using -dtall-page-formats not sufficient for your use case?
If you expect a 1-to-1 mapping between SVG files and MIDI files,
you can just put each piece into its own \book, with the
\bookOutputName of your choice, and compile it with
-dtall-page-formats=svg, and that should give you your desired
output files without suffixes.
Thanks, Jean.
That indeed does produce 1-to-1 mappings without suffices:
\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'tall-page-formats 'png,svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\header { tagline = ##f }
\book {
\bookOutputName "Foo"
\score { { f' } \layout { } \midi { } }
}
\book {
\bookOutputName "Abc"
\score { { a' } \layout { } \midi { } }
}
\book {
\bookOutputName "Bar"
\score { { b' } \layout { } \midi { } }
}
Each book has a layout and a midi, with the layout rendered both
as png and svg, properly cropped and with no -1 suffix in any file names:
-rwxrwxrwx+ 1 J None 451 Mar 30 21:37 MWE-SVG-tall.ly
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37 Foo.mid
-rwxrwxrwx+ 1 J None 6498 Mar 30 21:37 Foo.svg
-rwxrwxrwx+ 1 J None 2421 Mar 30 21:37 Foo.png
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37 Abc.mid
-rwxrwxrwx+ 1 J None 6490 Mar 30 21:37 Abc.svg
-rwxrwxrwx+ 1 J None 2401 Mar 30 21:37 Abc.png
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37 Bar.mid
-rwxrwxrwx+ 1 J None 6530 Mar 30 21:37 Bar.svg
-rwxrwxrwx+ 1 J None 2377 Mar 30 21:37 Bar.png
Here is Bar.svg
Bar.svg
and Bar.png (at default low resolution of 101)
Bar.png
Both are properly cropped, as opposed to whole (tall?) pages.
I think what threw me off using tall-page-formats were conclusions on
https://lists.gnu.org/archive/html/lilypond-user/2023-03/msg00029.html
https://lists.gnu.org/archive/html/lilypond-user/2023-02/msg00070.html
https://gitlab.com/lilypond/lilypond/-/issues/6235
saying "this combination of options appears to produce cropped output"
#(ly:set-option 'separate-page-formats 'eps,png,pdf)
#(ly:set-option 'use-paper-size-for-page #f)
Going back to the manuals didn't help explain tall-page-formats:
The 2.24 usage manual defines tall-page-formats as
"Comma-separated list of formats (svg, pdf, png, or eps)
to use for the ‘tall page’ image in lilypond-book."
But I couldn't find "tall page" in the usage pages for lilypond-book
nor in the LilyPond index for either the usage manual or NR.
I did find this oblique mention near the end of the 2.24 Changes doc
(in the Miscellaneous Improvements section) regarding "the default of
the aux-files program option changed to #f" (I never use that option):
"The formats for lilypond-book images can be set separately for
the tall page image (typically PNG for HTML output) and per-system
images (typically, EPS or PDF for printed output) with the -d
sub-options -dtall-page-formats and -dseparate-page-formats
respectively."
Based on these limited descriptions and discussions, and my requirement
for properly cropped multi-system scores in separate image files, as
opposed to un-cropped whole pages (tall pages?), I'd still think
separate-page-formats should work.
Maybe the documentation of separate- and tall-page-formats
should elaborate more.
Or am I still missing the one place where that explanation is provided?
Thanks for your patience!
Jeff
Re: bookOutputName still gets "-1" suffix added to SVG file names
On 3/30/2023 10:11 AM, David Wright wrote: 32 -rwxrwxrwx+ 1 J None 32199 Mar 29 22:25 Foo-1.svg* 32 -rwxrwxrwx+ 1 J None 32190 Mar 29 22:25 Abc-1.svg* 32 -rwxrwxrwx+ 1 J None 32231 Mar 29 22:25 Bar-1.svg* That looks like a linux platform. But it's Windows 10 running the cygwin.dll (see http://cygwin.com/ and https://en.wikipedia.org/wiki/Cygwin) If the thousand-odd files are in a single directory, and you like visual interfaces, renaming them is very simple in a TUI-style file manager like Midnight Commander (mc). You'd rename (called Move) from *-1.svg to *.svg after selecting all the files with the * keystroke. If you prefer a CLI, then it's as simple as: $ cd directory-containing-files $ rename 's/-1\.svg$/.svg/' *.svg except for the complication of which version of rename you have installed on your system. I prefer the version that uses a Perl expression, and it's set up as the default on my system for the "rename" command, but can also be invoked as prename or file-rename. Where files are scattered amongst directories, the CLI rename command can be invoked from a find command, which searches directory trees for suitable filenames to rename. Cheers, David. Thanks for your detailed assistance, David! The rename command in my cygwin doesn't look like it takes Perl REs, which I'd prefer instead: $ rename -V rename from util-linux 2.33.1 SYNOPSIS rename [options] expression replacement file... DESCRIPTION rename will rename the specified files by replacing the first occurrence of expression in their name by replacement. But as this is part of my process going forward, I'll probably use bash pattern matching or write a Perl script. If it's just removing the "-1" it's easy, as you indicate. But the MidiMismatch example that I showed Jean would be more difficult. Still holding out hope that ly developers may take the suggestion I made to Jean, which would allow everything to be resolved inside ly. Thx again, Jeff
Re: bookOutputName still gets "-1" suffix added to SVG file names
Le jeudi 30 mars 2023 à 18:31 -0600, Jeff Olson a écrit :
> Understood, but, like midi, the first file could (should) still have
> been un-suffixed.
> And the current mismatch between layout files and midi files is a
> good reason for the opposite:
> Consider this MWE named MidiMismatch.ly that generates pairs of svg
> and midi files:
> \version "2.24.1"
> #(ly:set-option 'backend 'cairo)
> #(ly:set-option 'separate-page-formats 'svg)
> #(ly:set-option 'use-paper-size-for-page #f)
> #(ly:set-option 'point-and-click #f)
> \header { tagline = ##f }
> \paper { print-page-number = ##f }
> \score { { f' } \layout { } \midi { } }
> \pageBreak
> \score { { a' } \layout { } \midi { } }
> \pageBreak
> \score { { b' } \layout { } \midi { } }
> The suffices of its generated svg files are **off by one** from the
> midi files:
> 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch.mid*
> 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-1.mid*
> 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-2.mid*
> 8 -rwxrwxrwx+ 1 J None 6496 Mar 30 17:15 MidiMismatch-1.svg*
> 8 -rwxrwxrwx+ 1 J None 6502 Mar 30 17:15 MidiMismatch-2.svg*
> 8 -rwxrwxrwx+ 1 J None 6510 Mar 30 17:15 MidiMismatch-3.svg*
I disagree that this can be considered "off by one", for two reasons.
* It only happens if you have a sequence of scores that are all
separated by a `\pageBreak`, and you separate-page-output.
Namely, you are close to trying to generate one SVG and one
MIDI file per score. Then why not just make separate \books?
* As soon as one of the scores takes more than one page, it breaks
the pairing anyway. Comparing a sequence of scores with a sequence
of pages when each score may result in several pages is
comparing apples with oranges.
> > By the way, in addition to simplifying automation (like lilypond-
> > book),
> The above example shows how this creates an automation nightmare.
That's not what I would call a nightmare. What would be a real
nightmare would be making it impossible to have separate-page
and tall-page output in the same run, doubling the compilation
time required to get all the desired outputs. Or adding the -1.svg
suffix only for the first page of separate-page output only there
is also tall-page output, which would mean you could write a working
script using separate-page output, then add tall-page output, and
it would break your previous work.
> > having -1.svg even on the first page makes it possible to use both
> > separate-page-formats and tall-page-formats at the same time.
> So I added "#(ly:set-option 'tall-page-formats 'svg)" to the example
> above
> and it produced MidiMismatch.svg (with three scores) which is what I
> assume you mean.
> It had no effect on the off-by-one between midi and svg, of course.
> Nevertheless, couldn't the suffixing algorithm in all cases still
> start with
> the un-suffixed named and add suffices only to resolve actual
> collisions?
> Removing the tall-page-formats line would then have begun with
> MidiMismatch.svg
> matching MidiMismatch.mid (the note f') and all subsequent files
> would also match.
See above for why this is not desirable in my book.
> And that would also have enabled bookOutputName in my original
> example to have
> complete control over the whole file name (with only one file per
> book).
> As it stands, it seems I'd have to use techniques outside of
> lilypond,
> as David W suggests, in order to correct the filenames. Is that
> what you're implying?
I don't understand the problem you're having. Is my suggestion of
using -dtall-page-formats not sufficient for your use case?
If you expect a 1-to-1 mapping between SVG files and MIDI files,
you can just put each piece into its own \book, with the
\bookOutputName of your choice, and compile it with
-dtall-page-formats=svg, and that should give you your desired
output files without suffixes.
The resulting SVGs will be concatenations of pages (each with
its page number for example, just all pages squashed together
in the same output file), but you can also use ly:one-page-breaking
if you want only one continuous page.
signature.asc
Description: This is a digitally signed message part
Re: bookOutputName still gets "-1" suffix added to SVG file names
On 3/29/2023 11:57 PM, Jean Abou Samra wrote:
These "-1" suffices are messing with my URLs for the SVG files,
so I'd appreciate any ideas on how to get rid of them. Thx.
They are there for good reason. If any of your |\book|s got output on
multiple pages, there would indeed be multiple files output.
Understood, but, like midi, the first file could (should) still have
been un-suffixed.
And the current mismatch between layout files and midi files is a good
reason for the opposite:
Consider this MWE named MidiMismatch.ly that generates pairs of svg and
midi files:
\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'separate-page-formats 'svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\header { tagline = ##f }
\paper { print-page-number = ##f }
\score { { f' } \layout { } \midi { } }
\pageBreak
\score { { a' } \layout { } \midi { } }
\pageBreak
\score { { b' } \layout { } \midi { } }
The suffices of its generated svg files are **off by one** from the midi
files:
1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch.mid*
1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-1.mid*
1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-2.mid*
8 -rwxrwxrwx+ 1 J None 6496 Mar 30 17:15 MidiMismatch-1.svg*
8 -rwxrwxrwx+ 1 J None 6502 Mar 30 17:15 MidiMismatch-2.svg*
8 -rwxrwxrwx+ 1 J None 6510 Mar 30 17:15 MidiMismatch-3.svg*
By the way, in addition to simplifying automation (like lilypond-book),
The above example shows how this creates an automation nightmare.
having |-1.svg| even on the first page makes it possible to use both
|separate-page-formats| and |tall-page-formats| at the same time.
So I added "#(ly:set-option 'tall-page-formats 'svg)" to the example above
and it produced MidiMismatch.svg (with three scores) which is what I
assume you mean.
It had no effect on the off-by-one between midi and svg, of course.
Nevertheless, couldn't the suffixing algorithm in all cases still start with
the un-suffixed named and add suffices only to resolve actual collisions?
Removing the tall-page-formats line would then have begun with
MidiMismatch.svg
matching MidiMismatch.mid (the note f') and all subsequent files would
also match.
And that would also have enabled bookOutputName in my original example
to have
complete control over the whole file name (with only one file per book).
As it stands, it seems I'd have to use techniques outside of lilypond,
as David W suggests, in order to correct the filenames. Is that what
you're implying?
Thx,
Jeff
Rehearsal Mark and textMark side by side?
Is there a way to combine a rehearsal mark with some text following it
other than the rather crude
\version "2.24.0"
{
c'' \mark \default c'' c'' c'' \textEndMark \markup {a tempo}
}
where the durations of the notes are chosen to make text follow the
rehearsal mark?
Richard
Re: bookOutputName still gets "-1" suffix added to SVG file names
On Thu 30 Mar 2023 at 07:57:23 (+0200), Jean Abou Samra wrote: > Le mercredi 29 mars 2023 à 22:56 -0600, Jeff Olson a écrit : > > I've got to generate a thousand+ cropped SVG files with specified file > > names > > from one lilypond compilation, so I'm wrapping each score in a \book with > > its own \bookOutputName as in this MWE: > > But the SVG files all have the extra -1 suffix as though there were > > additional > > files from the same book that would collide: > > > > 32 -rwxrwxrwx+ 1 J None 32199 Mar 29 22:25 Foo-1.svg* > > 32 -rwxrwxrwx+ 1 J None 32190 Mar 29 22:25 Abc-1.svg* > > 32 -rwxrwxrwx+ 1 J None 32231 Mar 29 22:25 Bar-1.svg* That looks like a linux platform. > > My MIDI files don't have this problem since they only add a suffix on > > **subsequent** files with the same base name, and there's only one per book. > > > > These "-1" suffices are messing with my URLs for the SVG files, > > so I'd appreciate any ideas on how to get rid of them. Thx. > > They are there for good reason. If any of your `\book`s got output on > multiple pages, there would indeed be multiple files output. > > If you never want separate pages, you should not use `separate-page-formats` > but `tall-page-formats`. > > By the way, in addition to simplifying automation (like lilypond-book), > having `-1.svg` even on the first page makes it possible to use both > `separate-page-formats` and `tall-page-formats` at the same time. If the thousand-odd files are in a single directory, and you like visual interfaces, renaming them is very simple in a TUI-style file manager like Midnight Commander (mc). You'd rename (called Move) from *-1.svg to *.svg after selecting all the files with the * keystroke. If you prefer a CLI, then it's as simple as: $ cd directory-containing-files $ rename 's/-1\.svg$/.svg/' *.svg except for the complication of which version of rename you have installed on your system. I prefer the version that uses a Perl expression, and it's set up as the default on my system for the "rename" command, but can also be invoked as prename or file-rename. Where files are scattered amongst directories, the CLI rename command can be invoked from a find command, which searches directory trees for suitable filenames to rename. Cheers, David.
Re: Height of markup entered on a Dynamics Staff
On Wed, 2023-03-29 at 10:03 -0700, Knute Snortum wrote:
> On Wed, Mar 29, 2023 at 5:08 AM Richard Shann <
> rich...@rshann.plus.com> wrote:
> > In the following snippet the text is displaced vertically upwards
> > if
> > the commenting out is removed, i.e. a note appears with more than
> > one
> > leger line later on the staff.
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > \version "2.24"
> > MI = {
> > <> ^\markup \bold \italic {"text" }
> > R1*4/4
> > R1*4/4
> > }
> > MII = {
> > R1*4/4
> > R1*4/4
> > c''1
> > %c'''1
> >
> > }
> > \score {
> > <<
> > \new Dynamics \MI
> > \new Staff \MII
> > >>
> > }
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> >
> > Is this a bug?
> >
>
>
> Hmm... I'm not seeing anything I would call a bug when I run your
> example. Here's what it looks like (attached).
the thing that was troubling me was that when uncommenting the higher
note the position of the text moved without it seemed any need to. I
understand why now, so that's ok.
Richard
>
> --
> Knute Snortum
Re: Height of markup entered on a Dynamics Staff
On Wed, 2023-03-29 at 20:05 +0200, Jean Abou Samra wrote:
> Le mercredi 29 mars 2023 à 13:07 +0100, Richard Shann a écrit :
> > In the following snippet the text is displaced vertically upwards
> > if
> > the commenting out is removed, i.e. a note appears with more than
> > one
> > leger line later on the staff.
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8>< \version "2.24"
> > MI = {
> > <> ^\markup \bold \italic {"text" }
> > R14/4
> > R14/4
> > }
> > MII = {
> > R14/4
> > R14/4
> > c''1
> > %c'''1
> >
> > }
> > \score {
> > <<
> > \new Dynamics \MI
> > \new Staff \MII
> > >>
> > }
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > Is this a bug?
> I don't think so. The point of the Dynamics context is to align the
> dynamics put into it on a common baseline. If there were another
> ^\markup ... at the point of that note with a ledger line, the
> alignment would force the first markup to much higher (just add s1
> s1^"text" in MI to see it). There is a tradeoff between making the
> line of dynamics look like it's consistently above the staff and not
> pushing it farther than necessary from the staff. I think LilyPond's
> behavior here is legitimate, though perhaps the text script should go
> higher than it does (with the ledgered note).
Ah, I understand, it comes down to me abusing the purpose of
DynamicsStaff .. thinking cap on.
Richard
Re: Anybody else playing with GPT4 and Lilypond?
This is nothing to do with GPT4, or guitars, so might be considered off-topic :) , but I'm aware of this paper due to Percival et al., which addresses sight-reading exercise generation: https://www.researchgate.net/publication/235925970_Generating_Targeted_Rhythmic_Exercises_for_Music_Students_with_Constraint_Satisfaction_Programming On 30/03/2023 05:57, Mike Blackstock wrote: re. "Anybody else playing with GPT4 and Lilypond?" I'm very much interestedin exploring its use to generate graded sight-reading material. My own instrument is classical guitar and we're not the best sight-readers[1]... it would be nice to have daily sight-reading exercises generated for practice, with midi. I could donate the use of a QEMU/KVM server instance for working on a project of that sort. [1] Guitarist John Williams: "Another thing I’ve noticed in master classes, is that players will come on and play the most difficult solo works from memory, and yet if you give them a part to play in one of the easier Haydn String Quartets, as I often do, they’re lost in no time, and have a very poor sense of ensemble or timing. Guitarists are among the worst sight-readers I’ve come across. Julian Bream and I are both dead average sight-readers by orchestral standards, but among guitarists, we are [considered] outstanding! " https://guitarteacher.com.au/interview/john-williams-interview/ On Wed, 29 Mar 2023 at 18:44, Saul Tobin wrote: I've seen some examples of other people succeeding in getting ChatGPT with GPT4 to compose simple music in other text based music formats. I've had limited success getting it to output Lilypond code. It is able to correctly structure the code with a score block, nested contexts, and appropriately named variables, and bar checks at the end of each measure. It seems to struggle to create rhythms that fit within the time signature beyond extremely simple cases. It also seems to struggle a lot to understand what octave pitches will be in when using relative mode. It also seems to have a lot of trouble keeping track of the relationship between notes entered in different simultaneous expressions. Just asking it to repeat back which notes appear in each voice on each beat, GPT4 frequently gives stubbornly incorrect answers about the music it generated. This makes it very difficult to improve its output by giving feedback. I'm curious whether anybody else has tried playing with this. I have to imagine that GPT4 has the potential to produce higher quality Lilypond output, given some of the other impressive things it can do. Perhaps it needs to be provided with a large volume of musical repertoire in Lilypond format. -- https://blackstock.media
