tuplet error

[Craig Dabelstein]

Hi lilyponders,

In the following MWE I get this error: *omitting tuplet bracket with
neither left nor right bound*

The compilation is fine. Anything I should do about this error?

Thanks,

Craig



\version "2.19.82"
\language "english"

flute = \relative c'' {
  \tuplet 3/2 4 {
g2.:8
a2.:8
bf2.:8
bf2.:8
  } |

}

\score {
  \new Staff
  \flute
  \layout { }
}

-- 
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com
*http://maximesmusic.com *
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Include path syntax on Mac

[Hans Åberg]

> On 23 Aug 2018, at 23:26, David Wright  wrote:
> 
> On Thu 23 Aug 2018 at 21:47:51 (+0200), Hans Åberg wrote:
>> 
 GCC works like with PATH, using first occurrence only. So the compiler 
 system files can be overridden that way.
>>> 
>>> Yes, but the preprocessor can distinguish the system's #include files
>>> from the user's own ones with  and "foo".
>> 
>> LilyPond does not have that; I have no preferences whether it should.
> 
> I know LP doesn't have that. What I can't discern is whether you
> *expect* the LP commandline to behave just like a GCC one, or whether
> you *want* it to. IOW I couldn't understand the sentiment behind your
> "Normally in compilers, …" about four messages back.

LilyPond must work which is best for what it does, but if it is not what is 
expected, like when it chooses some other file, it leads to hard to catch 
errors.

 LilyPond has system files named like makam.ly, which is natural to use in 
 ones own code. I think that then these are preferred rather than the local 
 ones, which can be confusing.
>>> 
>>> Exactly. The /ly/*.ly files must be available in
>>> order for LP to behave as documented. But unlike with C, they pollute
>>> both the user's library paths *and* the user's source-file paths.
>> 
>> One might get rid of that by adding <…>, and change "…" to first search the 
>> user directory. It would not affect any old lilypond code, I think, because 
>> if there are name clashes as it is now, the user code cannot be run.
>> 
>>> Compounded with the problems caused by -o, there's probably every
>>> reason to use an absolute path for the LP input file, particularly
>>> in scripts. Perhaps the file handling could be revamped when the
>>> major change in relative-includes is made (from #f to #t).
>> 
>> Also -o I would expect to be relative the current directory. Autotools 
>> would expect that: if one compiles out of the source directory, then the 
>> generated files should normally end up in the build directory.
> 
> I think -o *is* resolved relative to the current directory if it's a
> relative path. The problem is that given, say:
> 
> ~/here $ lilypond -o ../there/ source.ly
> 
> the output looks like:
> 
> GNU LilyPond 2.19.82
> Changing working directory to: `../there'
> Processing `source.ly'
> Parsing...
> /usr/share/lilypond/2.19.82/ly/init.ly:43:1: error: cannot find file: 
> `source.ly'
> 
> which implies that LP is trying to find here/../there/source.ly instead
> of here/source.ly which is what the user intended. LP needs to resolve
> all the relative paths on the commandline from $PWD *before* it
> changes the value of $PWD itself.
 
 With GCC, only one item after -o belong to this option; additional ones 
 are interpreted without the -o.
>>> 
>>> Sure. LP is the same: you can only write the output to one directory,
>>> or construct output filenames around one basic string. That wasn't my
>>> point. The problem is cd-ing to -o's directory *before* resolving the
>>> paths on the commandline (restating the paragraph above).
>> 
>> GCC does not change the directory trying to pass it to -o as you wrote 
>> above; just a weird error I think.
> 
> Again, I don't understand why you bring up GCC. AIUI GCC writes
> a single file, and -o overrides its default name and location.
> 
> LP is different. It can write many output files, so since 2.14 -o
> allows a directory name. But where you want to place the output
> shouldn't affect the input files at all.

Take Bison then, which writes multiple files. Then, running in directory tmp2
   bison -o ../tmp3/parser.cc ../tmp1/parser.yy
reads the input ../tmp1/parser.yy and writes all files where the main output 
file is, in ../tmp3/, and tmp2 remains empty.

So that is, I gather, what you would want with 
  lilypond -o ../tmp3/ ../tmp1/input.ly
but which it doesn't.

> But summarising to try to avoid misunderstanding of my opinions, I
> think that -I affecting the main input source file is a documented,
> intended misfeature, the -o problem is an undocumented, unintended
> feature, and the ly/foo.ly nameclash problem is something that might
> be unavoidable for -I include files (but not the main input file).

It may not be a problem for those that only use LilyPond and read the manual 
very carefully. I just note that it is conceptually different from programs 
like GCC and Bison, and from that viewpoint seems to invite hard to catch 
errors.



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Include path syntax on Mac

[David Wright]

On Thu 23 Aug 2018 at 21:47:51 (+0200), Hans Åberg wrote:
> 
> > On 23 Aug 2018, at 21:12, David Wright  wrote:
> > 
> > On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote:
> >>> On 16 Aug 2018, at 22:35, David Wright  wrote:
> >>> 
>  There I would expect -I to be put ahead of the program system 
>  directories, so those latter can be overridden. I think GCC in the past 
>  may have had another behavior, and GCC 8 maybe added more options to 
>  regulate in detail.
> >>> 
> >>> I'm not sure that is how LP is intended to work. I think the idea
> >>> would be that you redefine or override the assignments made by those
> >>> files if you want to change things and to do that, your files need
> >>> to run after LP's rather than preventing their interpretation entirely.
> >> 
> >> GCC works like with PATH, using first occurrence only. So the compiler 
> >> system files can be overridden that way.
> > 
> > Yes, but the preprocessor can distinguish the system's #include files
> > from the user's own ones with  and "foo".
> 
> LilyPond does not have that; I have no preferences whether it should.

I know LP doesn't have that. What I can't discern is whether you
*expect* the LP commandline to behave just like a GCC one, or whether
you *want* it to. IOW I couldn't understand the sentiment behind your
"Normally in compilers, …" about four messages back.

> >> LilyPond has system files named like makam.ly, which is natural to use in 
> >> ones own code. I think that then these are preferred rather than the local 
> >> ones, which can be confusing.
> > 
> > Exactly. The /ly/*.ly files must be available in
> > order for LP to behave as documented. But unlike with C, they pollute
> > both the user's library paths *and* the user's source-file paths.
> 
> One might get rid of that by adding <…>, and change "…" to first search the 
> user directory. It would not affect any old lilypond code, I think, because 
> if there are name clashes as it is now, the user code cannot be run.
> 
> > Compounded with the problems caused by -o, there's probably every
> > reason to use an absolute path for the LP input file, particularly
> > in scripts. Perhaps the file handling could be revamped when the
> > major change in relative-includes is made (from #f to #t).
>  
>  Also -o I would expect to be relative the current directory. Autotools 
>  would expect that: if one compiles out of the source directory, then the 
>  generated files should normally end up in the build directory.
> >>> 
> >>> I think -o *is* resolved relative to the current directory if it's a
> >>> relative path. The problem is that given, say:
> >>> 
> >>> ~/here $ lilypond -o ../there/ source.ly
> >>> 
> >>> the output looks like:
> >>> 
> >>> GNU LilyPond 2.19.82
> >>> Changing working directory to: `../there'
> >>> Processing `source.ly'
> >>> Parsing...
> >>> /usr/share/lilypond/2.19.82/ly/init.ly:43:1: error: cannot find file: 
> >>> `source.ly'
> >>> 
> >>> which implies that LP is trying to find here/../there/source.ly instead
> >>> of here/source.ly which is what the user intended. LP needs to resolve
> >>> all the relative paths on the commandline from $PWD *before* it
> >>> changes the value of $PWD itself.
> >> 
> >> With GCC, only one item after -o belong to this option; additional ones 
> >> are interpreted without the -o.
> > 
> > Sure. LP is the same: you can only write the output to one directory,
> > or construct output filenames around one basic string. That wasn't my
> > point. The problem is cd-ing to -o's directory *before* resolving the
> > paths on the commandline (restating the paragraph above).
> 
> GCC does not change the directory trying to pass it to -o as you wrote above; 
> just a weird error I think.

Again, I don't understand why you bring up GCC. AIUI GCC writes
a single file, and -o overrides its default name and location.

LP is different. It can write many output files, so since 2.14 -o
allows a directory name. But where you want to place the output
shouldn't affect the input files at all.

But summarising to try to avoid misunderstanding of my opinions, I
think that -I affecting the main input source file is a documented,
intended misfeature, the -o problem is an undocumented, unintended
feature, and the ly/foo.ly nameclash problem is something that might
be unavoidable for -I include files (but not the main input file).

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Proprietary Software term

[Ben]

On 8/23/2018 4:57 PM, Urs Liska wrote:



Urs mentions encryption being used by CodaMusic (I've never heard
of them) and that clearly shows an intention of lock-in. OTOH Wols
doesn't lay out here the evidence of the reported intent of Word's
changes. (Actually, I thought it was an open format nowadays.)


Coda Music was the original company re: Finale, way back in the day
before it was sold and became MakeMusic eventually.

I was indeed referring to Finale. At some point (around Finale 2014 or so) the 
company was purchased by an investment company, and one of the first decisions 
was to create an encrypted file format. AFAIK this decision has been reversed 
by now.


I think you're right but honestly, things haven't been the same with 
Finale since the company was bought out...again. And those changes 
madeagain. Yikes.


https://www.webcitation.org/6OerqSdg5  <-- Interesting read...

Plain text sure does look attractive.  :)


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Proprietary Software term

[Urs Liska]

Am 23. August 2018 22:27:33 MESZ schrieb Ben :
>On 8/23/2018 4:21 PM, David Wright wrote:
>> On Sat 18 Aug 2018 at 22:18:51 (+0200), David Kastrup wrote:
>>> David Wright  writes:
>>>
 On Sat 18 Aug 2018 at 19:55:01 (+0100), Wols Lists wrote:
> On 18/08/18 12:51, David Kastrup wrote:
>>> Indeed, that wasn't expressed too well. What I meant is that
 CodaMusic's policy to use binary non-released (for some time
>even
 encrypted) file formats strongly discouraged anyone to make a
>program
 use these files.
>> That's more than just lock-in.  Don't know a good expression, but
>that's
>> more like locked-away (don't know a good expression for it) since
>the
>> format is designed to keep the user from being able to access his
>own
>> information (and/or that of others).  In my book, that's a no-no
>since
>> it renders archiving worthless.
>>
> Undocumented proprietary format.
>
> I compare WordPerfect with Word ... Word's format seems to change
>with
> almost every release, the changes being in many cases apparently
>to
> interfere with compatibility with other programs.
>
> While WordPerfect's format, although proprietary, was
>well-documented,
> with defined extensibility, and a guarantee of compatibility. To
>the
> extent that WordPerfect 6, released in 1994, is to the best of my
> knowledge capable of editing and saving - WITHOUT DAMAGING IT - a
>file
> created by the latest version. So any WordPerfect-compatible
>program
> should be able to do the same.
 "Undocumented proprietary format" doesn't express the intent which
 "lock-in" does. As David pointed out, patents can be used to
>protect
 a proprietary format, only I don't think that, for example, the
>exFAT
 filesystem is, in his words, a "strange case".
>>> A filesystem is not a file format.
>>
>> Urs mentions encryption being used by CodaMusic (I've never heard
>> of them) and that clearly shows an intention of lock-in. OTOH Wols
>> doesn't lay out here the evidence of the reported intent of Word's
>> changes. (Actually, I thought it was an open format nowadays.)
>>
>
>Coda Music was the original company re: Finale, way back in the day 
>before it was sold and became MakeMusic eventually.

I was indeed referring to Finale. At some point (around Finale 2014 or so) the 
company was purchased by an investment company, and one of the first decisions 
was to create an encrypted file format. AFAIK this decision has been reversed 
by now.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Proprietary Software term

[Ben]

On 8/23/2018 4:21 PM, David Wright wrote:

On Sat 18 Aug 2018 at 22:18:51 (+0200), David Kastrup wrote:

David Wright  writes:


On Sat 18 Aug 2018 at 19:55:01 (+0100), Wols Lists wrote:

On 18/08/18 12:51, David Kastrup wrote:

Indeed, that wasn't expressed too well. What I meant is that

CodaMusic's policy to use binary non-released (for some time even
encrypted) file formats strongly discouraged anyone to make a program
use these files.

That's more than just lock-in.  Don't know a good expression, but that's
more like locked-away (don't know a good expression for it) since the
format is designed to keep the user from being able to access his own
information (and/or that of others).  In my book, that's a no-no since
it renders archiving worthless.


Undocumented proprietary format.

I compare WordPerfect with Word ... Word's format seems to change with
almost every release, the changes being in many cases apparently to
interfere with compatibility with other programs.

While WordPerfect's format, although proprietary, was well-documented,
with defined extensibility, and a guarantee of compatibility. To the
extent that WordPerfect 6, released in 1994, is to the best of my
knowledge capable of editing and saving - WITHOUT DAMAGING IT - a file
created by the latest version. So any WordPerfect-compatible program
should be able to do the same.

"Undocumented proprietary format" doesn't express the intent which
"lock-in" does. As David pointed out, patents can be used to protect
a proprietary format, only I don't think that, for example, the exFAT
filesystem is, in his words, a "strange case".

A filesystem is not a file format.


Urs mentions encryption being used by CodaMusic (I've never heard
of them) and that clearly shows an intention of lock-in. OTOH Wols
doesn't lay out here the evidence of the reported intent of Word's
changes. (Actually, I thought it was an open format nowadays.)



Coda Music was the original company re: Finale, way back in the day 
before it was sold and became MakeMusic eventually.



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Proprietary Software term

[David Wright]

On Sat 18 Aug 2018 at 22:18:51 (+0200), David Kastrup wrote:
> David Wright  writes:
> 
> > On Sat 18 Aug 2018 at 19:55:01 (+0100), Wols Lists wrote:
> >> On 18/08/18 12:51, David Kastrup wrote:
> >> >> Indeed, that wasn't expressed too well. What I meant is that
> >> >> > CodaMusic's policy to use binary non-released (for some time even
> >> >> > encrypted) file formats strongly discouraged anyone to make a program
> >> >> > use these files.
> >> 
> >> > That's more than just lock-in.  Don't know a good expression, but that's
> >> > more like locked-away (don't know a good expression for it) since the
> >> > format is designed to keep the user from being able to access his own
> >> > information (and/or that of others).  In my book, that's a no-no since
> >> > it renders archiving worthless.
> >> > 
> >> Undocumented proprietary format.
> >> 
> >> I compare WordPerfect with Word ... Word's format seems to change with
> >> almost every release, the changes being in many cases apparently to
> >> interfere with compatibility with other programs.
> >> 
> >> While WordPerfect's format, although proprietary, was well-documented,
> >> with defined extensibility, and a guarantee of compatibility. To the
> >> extent that WordPerfect 6, released in 1994, is to the best of my
> >> knowledge capable of editing and saving - WITHOUT DAMAGING IT - a file
> >> created by the latest version. So any WordPerfect-compatible program
> >> should be able to do the same.
> >
> > "Undocumented proprietary format" doesn't express the intent which
> > "lock-in" does. As David pointed out, patents can be used to protect
> > a proprietary format, only I don't think that, for example, the exFAT
> > filesystem is, in his words, a "strange case".
> 
> A filesystem is not a file format.

Sure. But it's a format, and it may be proprietary, and it may be
undocumented. The distinction I'm making encompasses a wider range of
instances than just *file* formats¹, and concerns itself with intent
rather than mechanism.

Urs mentions encryption being used by CodaMusic (I've never heard
of them) and that clearly shows an intention of lock-in. OTOH Wols
doesn't lay out here the evidence of the reported intent of Word's
changes. (Actually, I thought it was an open format nowadays.)

But as I'm not in the habit of using proprietary file formats,
it's not that easy to come up with good examples I know much
about, so I used a filesystem example instead.

In the past, AIUI it was necessary to obtain a licence to write
a file in a specific GIF format. While that was the case, it
would not be wise to try and circumvent the licence merely by
writing from scratch a program to write the file. Just saying the file
has a "proprietary format", whether documented or undocumented,
doesn't express the intent that "lock-in" does.

One filesystem (yes, filesystem) format that I *am* in the habit of
using, like countless others, is FAT32. Fortunately its MS patent has
been interpreted as meaning that you can create files with long
filenames, or with short ones, without a licence; but to create a file
with both types of filename, you need a licence. Not having one
proved expensive for TomTom.

With the AARD code I mentioned before, the boot was on the other foot
because its perceived intent fell foul of the US anti-trust laws.
I've read that that settlement cost MS $280M.

So that's my point: intent, and not just whether it's documented.

¹ Though as Wols pointed out, a filesystem is just a format in which
to write a particular type of file: a device file. If the file is
described in a hard drive's partition table, it will normally be
termed a "partition". One could make a backup copy with
# dd if=/dev/sdb1 of=/tmp/backup-copy

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Include path syntax on Mac

[Hans Åberg]

> On 23 Aug 2018, at 21:12, David Wright  wrote:
> 
> On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote:
>>> On 16 Aug 2018, at 22:35, David Wright  wrote:
>>> 
 There I would expect -I to be put ahead of the program system directories, 
 so those latter can be overridden. I think GCC in the past may have had 
 another behavior, and GCC 8 maybe added more options to regulate in detail.
>>> 
>>> I'm not sure that is how LP is intended to work. I think the idea
>>> would be that you redefine or override the assignments made by those
>>> files if you want to change things and to do that, your files need
>>> to run after LP's rather than preventing their interpretation entirely.
>> 
>> GCC works like with PATH, using first occurrence only. So the compiler 
>> system files can be overridden that way.
> 
> Yes, but the preprocessor can distinguish the system's #include files
> from the user's own ones with  and "foo".

LilyPond does not have that; I have no preferences whether it should.

>> LilyPond has system files named like makam.ly, which is natural to use in 
>> ones own code. I think that then these are preferred rather than the local 
>> ones, which can be confusing.
> 
> Exactly. The /ly/*.ly files must be available in
> order for LP to behave as documented. But unlike with C, they pollute
> both the user's library paths *and* the user's source-file paths.

One might get rid of that by adding <…>, and change "…" to first search the 
user directory. It would not affect any old lilypond code, I think, because if 
there are name clashes as it is now, the user code cannot be run.

> Compounded with the problems caused by -o, there's probably every
> reason to use an absolute path for the LP input file, particularly
> in scripts. Perhaps the file handling could be revamped when the
> major change in relative-includes is made (from #f to #t).
 
 Also -o I would expect to be relative the current directory. Autotools 
 would expect that: if one compiles out of the source directory, then the 
 generated files should normally end up in the build directory.
>>> 
>>> I think -o *is* resolved relative to the current directory if it's a
>>> relative path. The problem is that given, say:
>>> 
>>> ~/here $ lilypond -o ../there/ source.ly
>>> 
>>> the output looks like:
>>> 
>>> GNU LilyPond 2.19.82
>>> Changing working directory to: `../there'
>>> Processing `source.ly'
>>> Parsing...
>>> /usr/share/lilypond/2.19.82/ly/init.ly:43:1: error: cannot find file: 
>>> `source.ly'
>>> 
>>> which implies that LP is trying to find here/../there/source.ly instead
>>> of here/source.ly which is what the user intended. LP needs to resolve
>>> all the relative paths on the commandline from $PWD *before* it
>>> changes the value of $PWD itself.
>> 
>> With GCC, only one item after -o belong to this option; additional ones are 
>> interpreted without the -o.
> 
> Sure. LP is the same: you can only write the output to one directory,
> or construct output filenames around one basic string. That wasn't my
> point. The problem is cd-ing to -o's directory *before* resolving the
> paths on the commandline (restating the paragraph above).

GCC does not change the directory trying to pass it to -o as you wrote above; 
just a weird error I think.



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Include path syntax on Mac

[David Wright]

On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote:
> > On 16 Aug 2018, at 22:35, David Wright  wrote:
> > 
> >> There I would expect -I to be put ahead of the program system directories, 
> >> so those latter can be overridden. I think GCC in the past may have had 
> >> another behavior, and GCC 8 maybe added more options to regulate in detail.
> > 
> > I'm not sure that is how LP is intended to work. I think the idea
> > would be that you redefine or override the assignments made by those
> > files if you want to change things and to do that, your files need
> > to run after LP's rather than preventing their interpretation entirely.
> 
> GCC works like with PATH, using first occurrence only. So the compiler system 
> files can be overridden that way.

Yes, but the preprocessor can distinguish the system's #include files
from the user's own ones with  and "foo".

> LilyPond has system files named like makam.ly, which is natural to use in 
> ones own code. I think that then these are preferred rather than the local 
> ones, which can be confusing.

Exactly. The /ly/*.ly files must be available in
order for LP to behave as documented. But unlike with C, they pollute
both the user's library paths *and* the user's source-file paths.

> >>> Compounded with the problems caused by -o, there's probably every
> >>> reason to use an absolute path for the LP input file, particularly
> >>> in scripts. Perhaps the file handling could be revamped when the
> >>> major change in relative-includes is made (from #f to #t).
> >> 
> >> Also -o I would expect to be relative the current directory. Autotools 
> >> would expect that: if one compiles out of the source directory, then the 
> >> generated files should normally end up in the build directory.
> > 
> > I think -o *is* resolved relative to the current directory if it's a
> > relative path. The problem is that given, say:
> > 
> > ~/here $ lilypond -o ../there/ source.ly
> > 
> > the output looks like:
> > 
> > GNU LilyPond 2.19.82
> > Changing working directory to: `../there'
> > Processing `source.ly'
> > Parsing...
> > /usr/share/lilypond/2.19.82/ly/init.ly:43:1: error: cannot find file: 
> > `source.ly'
> > 
> > which implies that LP is trying to find here/../there/source.ly instead
> > of here/source.ly which is what the user intended. LP needs to resolve
> > all the relative paths on the commandline from $PWD *before* it
> > changes the value of $PWD itself.
> 
> With GCC, only one item after -o belong to this option; additional ones are 
> interpreted without the -o.

Sure. LP is the same: you can only write the output to one directory,
or construct output filenames around one basic string. That wasn't my
point. The problem is cd-ing to -o's directory *before* resolving the
paths on the commandline (restating the paragraph above).

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: start engraving at specified measure

[Michael Winter]

Thanks,

I did try that directive, but it seems to not keep my proportional notation.

Is that by design?

-Michael

On 8/23/18 6:22 PM, David Kastrup wrote:

Michael Winter  writes:


Hello,

Is it possible to start engraving at a specified measure or to omit
the first x measure.

Note that I am not trying to create a fragment here. I just want to
drop x given empty measures at the beginning of a particular staff
(without removing empty staves past a certain point).

I tried to temporarily turn on and off

Staff.VerticalAxisGroup.remove-empty

But that did not seem to work with multiple voices (at least the
reverting part).






___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: start engraving at specified measure

[David Kastrup]

Michael Winter  writes:

> Hello,
>
> Is it possible to start engraving at a specified measure or to omit
> the first x measure.
>
> Note that I am not trying to create a fragment here. I just want to
> drop x given empty measures at the beginning of a particular staff
> (without removing empty staves past a certain point).
>
> I tried to temporarily turn on and off
>
> Staff.VerticalAxisGroup.remove-empty
>
> But that did not seem to work with multiple voices (at least the
> reverting part).



-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

start engraving at specified measure

[Michael Winter]

Hello,

Is it possible to start engraving at a specified measure or to omit the 
first x measure.


Note that I am not trying to create a fragment here. I just want to drop 
x given empty measures at the beginning of a particular staff (without 
removing empty staves past a certain point).


I tried to temporarily turn on and off

Staff.VerticalAxisGroup.remove-empty

But that did not seem to work with multiple voices (at least the 
reverting part).


Thanks,

Michael.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user