Re: Consistent vertical alignment of annotations, disable time signiture

[Jacques Menu Muzhic]

Ooops, that was in Oslo, Norway, not Sweden...

> Le 18 avr. 2018 à 21:47, Jacques Menu Muzhic  a écrit :
> 
> In compiler technology, ‘object code’ refers to the code generated by a 
> compiler, containing the same semantical information as the ’source code’ 
> that has been compiled, but in a form better suited for the task at hand. 
> Quite often, the goal is execution by a physical or virtual processor.
> 
> This term was coined decades back, long long before the object orientation 
> was invented in Sweden by the Simula-67 team (the class concept, grouping 
> data and the operations that work on them), though… Hey, that was 51 years 
> ago!
> 
> From this point of view, the Scheme data structures built by the LilyPond 
> compiler are a form of object code: the semantical contents is the same 
> hopefully as that of the LilyPond code, and it’s better suited to the 
> production of nice scores.
> 
> JM
> 
>> Le 18 avr. 2018 à 17:22, Carl Sorensen  a écrit :
>> 
>> 
>> 
>> On 4/18/18, 6:51 AM, "Robert Hickman"  wrote:
>> 
>>   If lilypond is based on a functional interface, the documentation
>>   making extensive use of the terms 'object' and 'interface' is
>>   confusing.
>> 
>> Patches to documentation will be reviewed.  
>> http://lilypond.org/doc/v2.19/Documentation/contributor/documentation-work
>> 
>> Carl
>> 
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 


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

Re: Consistent vertical alignment of annotations, disable time signiture

[Jacques Menu Muzhic]

In compiler technology, ‘object code’ refers to the code generated by a 
compiler, containing the same semantical information as the ’source code’ that 
has been compiled, but in a form better suited for the task at hand. Quite 
often, the goal is execution by a physical or virtual processor.

This term was coined decades back, long long before the object orientation was 
invented in Sweden by the Simula-67 team (the class concept, grouping data and 
the operations that work on them), though… Hey, that was 51 years ago!

From this point of view, the Scheme data structures built by the LilyPond 
compiler are a form of object code: the semantical contents is the same 
hopefully as that of the LilyPond code, and it’s better suited to the 
production of nice scores.

JM

> Le 18 avr. 2018 à 17:22, Carl Sorensen  a écrit :
> 
> 
> 
> On 4/18/18, 6:51 AM, "Robert Hickman"  wrote:
> 
>If lilypond is based on a functional interface, the documentation
>making extensive use of the terms 'object' and 'interface' is
>confusing.
> 
> Patches to documentation will be reviewed.  
> http://lilypond.org/doc/v2.19/Documentation/contributor/documentation-work
> 
> Carl
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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

Re: Consistent vertical alignment of annotations, disable time signiture

[Carl Sorensen]

On 4/18/18, 6:51 AM, "Robert Hickman"  wrote:

If lilypond is based on a functional interface, the documentation
making extensive use of the terms 'object' and 'interface' is
confusing.

Patches to documentation will be reviewed.  
http://lilypond.org/doc/v2.19/Documentation/contributor/documentation-work

Carl

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Werner LEMBERG]

>> Can you suggest a better word to describe all the various things on
>> a page of musical notation (e.g., note head, flag, rest, stem, dot,
>> slur, etc.)?
> 
> No, but classifying it to say 'not related to OOP' would have avoided
> the confusion.

Yes, a remark into this direction should be added – too many users of
lilypond have experience with object-oriented programming...


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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

> Can you suggest a better word to describe all the various things on a page of 
> musical notation (e.g., note head, flag, rest, stem, dot, slur, etc.)?

No, but classifying it to say 'not related to OOP' would have avoided
the confusion.

I think my main point of confusion related to the term 'interface'
which appears to be used in the same sense of 'class implementing an
interface' in java-esque oop systems. 'This object must provide the
following methods'.

On 18 April 2018 at 15:13, Kieren MacMillan
 wrote:
> Hi Robert,
>
>> If lilypond is based on a functional interface, the documentation
>> making extensive use of the terms 'object' and 'interface' is confusing.
>
> Can you suggest a better word to describe all the various things on a page of 
> musical notation (e.g., note head, flag, rest, stem, dot, slur, etc.)?
>
> Thanks,
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>

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

Re: Consistent vertical alignment of annotations, disable time signiture

[David Kastrup]

Robert Hickman  writes:

> If lilypond is based on a functional interface, the documentation
> making extensive use of the terms 'object' and 'interface' is
> confusing.

LilyPond is not "based on a functional interface".  If you have concrete
examples of where the documentation rather than your preconceptions is
inaccurate, feel free to bring them up.

-- 
David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Kieren MacMillan]

Hi Robert,

> If lilypond is based on a functional interface, the documentation
> making extensive use of the terms 'object' and 'interface' is confusing.

Can you suggest a better word to describe all the various things on a page of 
musical notation (e.g., note head, flag, rest, stem, dot, slur, etc.)?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

If lilypond is based on a functional interface, the documentation
making extensive use of the terms 'object' and 'interface' is
confusing.

On 18 April 2018 at 13:35, Andrew Bernard  wrote:
> Hi Robert,
>
> Having just learned ABC, I see that it supports rolls, but not all the
> Larsen ornament notation. I see no reason why ABC can't be extended - there
> are many, dozens in fact, ABC editors that are open source. Worth looking
> into. It you can produce a trill in ABC, you can produce a cut.
>
> Andrew
>
>

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

Re: Consistent vertical alignment of annotations, disable time signiture

[David Kastrup]

Robert Hickman  writes:

> You are largely missing the point I was trying to make, however I have
> a lot of work to do and cannot be bothered to argue.

Good start.

> On 18 April 2018 at 13:24, David Kastrup  wrote:

[...]

>> So?  What are you hoping to gain by lecturing everyone how bad LilyPond
>> must have been designed according to your experience with and/or without
>> it?
>>
>> I mean, I am the last one to let a good opportunity for pontificating go
>> to waste, but so far I fail to see that you have availed yourself of
>> such an opportunity.  Perhaps try to figure out what you actually want
>> to get achieved and then think of plans, technical and/or social, to
>> actually get them done.
>>
>> There is no point playing to your strengths without applying them in a
>> useful manner to problems you want to see solved.

-- 
David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Andrew Bernard]

Hi Robert,

EasyABC, the one I am using, is open source. Would you like me to
investigate?

I think we are probably off topic by now.


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

Re: Consistent vertical alignment of annotations, disable time signiture

[Andrew Bernard]

Hi Robert,

Having just learned ABC, I see that it supports rolls, but not all the
Larsen ornament notation. I see no reason why ABC can't be extended - there
are many, dozens in fact, ABC editors that are open source. Worth looking
into. It you can produce a trill in ABC, you can produce a cut.

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

You are largely missing the point I was trying to make, however I have
a lot of work to do and cannot be bothered to argue.

On 18 April 2018 at 13:24, David Kastrup  wrote:
> Robert Hickman  writes:
>
>> The best example of the leaky abstraction problem I can think of right
>> now are actually visual HTML editors.
>
> That's more in line of complaining about Denemo than LilyPond.  Either
> way the solution lies in not confusing the editor's domain with the the
> result domain.
>
>> As David notes, I am talking about input layer not internals. The
>> lilypond syntax appears to be an abstraction over an object oriented
>> design,
>
> No, that definitely isn't it.  Absolutely not.
>
>> with a lot of implicit 'magic', and for me as a new user it is very
>> difficult to see why it does some things, like randomly creating an
>> empty staff. What I'm wandering is weather it would be clearer to just
>> use an object oriented syntax directly and make the implicit stuff
>> explicit.
>
> LilyPond is designed as an input language.  Its internal data structures
> are mostly mapped to Scheme data structures.  Scheme is a functional
> language, not an object oriented language.  Large swaths of LilyPond are
> coded in C++ for efficiency reasons, but the data models of C++ don't
> really have exposure worth noting to LilyPond.
>
> Understanding LilyPond's input is not related to understanding C++ and
> not significantly related to Scheme either.  Its input language is
> defined in a traditional lexer/parser manner implemented with a standard
> LALR(1) parser generator.  For debugging and programming reasons, its
> productions these days pass around Scheme data structures exclusively
> but that's a comparatively recent development.
>
> So no: you are completely wrong with your musings and they have
> absolutely no relation to internals of LilyPond: this rather concerns
> the completely independent syntax (and parser-internal semantics) of its
> input files.
>
>> ABC notation does most of what I need, but lacks a few minor
>> formatting controls and the ability to define symbols which I need to
>> finish the work that I'm doing. Lillypond seems vastly more
>> complicated than I need.
>
> If you don't insist into digging yourself into the complexity, you can
> get away perfectly well without it.  But you refuse doing so because you
> express your a priori confidence that its authors and maintainers are
> incapable of properly layering its complexity.
>
>> The learning manual spends most of it's time going into things that I
>> have no use for, such as multiple staff arrangements.
>
> If you want to pay for a personal tutor catering to your personal needs,
> of course you can save the time skipping over unwanted material.
> Manuals are a compromise between saving time for the teacher and saving
> time for the learner.  As we have a vastly larger number of users over
> teachers, they are freeing resources for the project.
>
>> Sheet music could either be complex or simple depending on what you
>> are trying to do, for what I'm doing a fixed-spacing 'dumb stacking
>> algorithm' that abcm2ps appears to use is perfectly adequate.
>
> So?  What are you hoping to gain by lecturing everyone how bad LilyPond
> must have been designed according to your experience with and/or without
> it?
>
> I mean, I am the last one to let a good opportunity for pontificating go
> to waste, but so far I fail to see that you have availed yourself of
> such an opportunity.  Perhaps try to figure out what you actually want
> to get achieved and then think of plans, technical and/or social, to
> actually get them done.
>
> There is no point playing to your strengths without applying them in a
> useful manner to problems you want to see solved.
>
> --
> David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[David Kastrup]

Robert Hickman  writes:

> The best example of the leaky abstraction problem I can think of right
> now are actually visual HTML editors.

That's more in line of complaining about Denemo than LilyPond.  Either
way the solution lies in not confusing the editor's domain with the the
result domain.

> As David notes, I am talking about input layer not internals. The
> lilypond syntax appears to be an abstraction over an object oriented
> design,

No, that definitely isn't it.  Absolutely not.

> with a lot of implicit 'magic', and for me as a new user it is very
> difficult to see why it does some things, like randomly creating an
> empty staff. What I'm wandering is weather it would be clearer to just
> use an object oriented syntax directly and make the implicit stuff
> explicit.

LilyPond is designed as an input language.  Its internal data structures
are mostly mapped to Scheme data structures.  Scheme is a functional
language, not an object oriented language.  Large swaths of LilyPond are
coded in C++ for efficiency reasons, but the data models of C++ don't
really have exposure worth noting to LilyPond.

Understanding LilyPond's input is not related to understanding C++ and
not significantly related to Scheme either.  Its input language is
defined in a traditional lexer/parser manner implemented with a standard
LALR(1) parser generator.  For debugging and programming reasons, its
productions these days pass around Scheme data structures exclusively
but that's a comparatively recent development.

So no: you are completely wrong with your musings and they have
absolutely no relation to internals of LilyPond: this rather concerns
the completely independent syntax (and parser-internal semantics) of its
input files.

> ABC notation does most of what I need, but lacks a few minor
> formatting controls and the ability to define symbols which I need to
> finish the work that I'm doing. Lillypond seems vastly more
> complicated than I need.

If you don't insist into digging yourself into the complexity, you can
get away perfectly well without it.  But you refuse doing so because you
express your a priori confidence that its authors and maintainers are
incapable of properly layering its complexity.

> The learning manual spends most of it's time going into things that I
> have no use for, such as multiple staff arrangements.

If you want to pay for a personal tutor catering to your personal needs,
of course you can save the time skipping over unwanted material.
Manuals are a compromise between saving time for the teacher and saving
time for the learner.  As we have a vastly larger number of users over
teachers, they are freeing resources for the project.

> Sheet music could either be complex or simple depending on what you
> are trying to do, for what I'm doing a fixed-spacing 'dumb stacking
> algorithm' that abcm2ps appears to use is perfectly adequate.

So?  What are you hoping to gain by lecturing everyone how bad LilyPond
must have been designed according to your experience with and/or without
it?

I mean, I am the last one to let a good opportunity for pontificating go
to waste, but so far I fail to see that you have availed yourself of
such an opportunity.  Perhaps try to figure out what you actually want
to get achieved and then think of plans, technical and/or social, to
actually get them done.

There is no point playing to your strengths without applying them in a
useful manner to problems you want to see solved.

-- 
David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

The best example of the leaky abstraction problem I can think of right
now are actually visual HTML editors. HTML is very complicated and
follows a 'WYSIWYM' model similar to LaTeX, however the visual editors
try to force this into a 'WYSIWYG' model which simply does not work,
especially when responsive layouts are a factor, as what you see is
inherently going to change. This tends to result in things breaking in
unexpected ways, because the user is not aware of the mismatch. Plus
these tools are usually only aware of a small subset of HTML, so if
they are used in combination with hand written code things get broken
as a result.

As David notes, I am talking about input layer not internals. The
lilypond syntax appears to be an abstraction over an object oriented
design, with a lot of implicit 'magic', and for me as a new user it is
very difficult to see why it does some things, like randomly creating
an empty staff. What I'm wandering is weather it would be clearer to
just use an object oriented syntax directly and make the implicit
stuff explicit.

ABC notation does most of what I need, but lacks a few minor
formatting controls and the ability to define symbols which I need to
finish the work that I'm doing. Lillypond seems vastly more
complicated than I need. The learning manual spends most of it's time
going into things that I have no use for, such as multiple staff
arrangements. Sheet music could either be complex or simple depending
on what you are trying to do, for what I'm doing a fixed-spacing 'dumb
stacking algorithm' that abcm2ps appears to use is perfectly adequate.

Irish trad music is different from classical tradition in that the
scores denote a simple 'outline' of a tune. How they are actually
played tends to differ a great deal, including implicit 'lilt' or
'swung' rhythms and ornamentation and melodic variations that are
added by the player, generally differently every single time they play
a tune. Outside of teaching materials it is rare to notate
articulations, slurs, or ornaments at all. Standard playing style
often attempts to emulate numerous historical bagpipes by slurring
everything by default, and using fingered articulations extensively.

I suspect that ABCn hasn't defined the Larson symbols both because of
the above, and because folk musicians often notate fingered
articulations using grace notes. However this notation requires
different interpretation from the usage of grace notes in classical
theory, and as a result only works within the scope of a given
tradition. It's also very open to misinterpretation if encountered by
classically trained musicians. Calling these 'grace notes' is also
misleading as they are used as articulations, basically
interchangeably with tonguing. They exploit the limits of human
perception by being extremely brief. When played well they are so
brief that their absolute pitch is not perceived. In order to do this
dependably special fingerings or techniques are used.  Grey Larson's
book recognises the mostly my last point, which lead to his notation
system.

On 18 April 2018 at 09:37, David Kastrup  wrote:
> Andrew Bernard  writes:
>
>> Hello Robert,
>>
>> Speaking as a programmer myself with over forty years of experience,
>> and an advanced lilypond users, I can categorically assert that
>> lilypond is not trying to be 'clever'. This is an utter
>> misunderstanding. Lilypond is however trying to engrave music to the
>> highest possible standard, and this is an immensely difficult
>> programming proposition, hence the complexity under the hood, and the
>> slight difficulties in the syntax. It's not meant to be simplistic or
>> easy like ABC.
>
> I hate to waste a good defense, but you are talking about its internals
> here and Robert was arguing about the input layer with me.  Different
> beasts.  It's akin to discussing plain TeX vs LaTeX based on the quality
> of the output.  The point of LaTeX is to provide an input and
> abstraction layer, the typesetting remains the job of TeX, the program.
> Now LaTeX is indeed bleeding complexity when you poke it too hard.
>
> LilyPond's input language is intended to be expressive and convenient
> but a whole lot of pain goes into assuring that it bleeds in concordance
> with both reasonable and unreasonable expectations even when you poke it
> too hard.
>
> As an example, compare the 2.19 version and interaction of of #{ ... #},
> $, and # with the 2.12 one.  The current version is quite "cleverer",
> going to large pains to make sure that closures, error messages and
> whatnot reliably point to where you'd expect them to be.  This is a much
> more thorough layer than LaTeX provides around TeX, and yet people feel
> much more comfortable using LaTeX than plain TeX.  The LaTeX layers fall
> apart when problems occur and you have to debug.  LilyPond layers tend
> to hold up even under debugging.
>
> Robert may be speaking from experience, but experience without actual
> 

Re: Consistent vertical alignment of annotations, disable time signiture

[David Kastrup]

Andrew Bernard  writes:

> Hello Robert,
>
> Speaking as a programmer myself with over forty years of experience,
> and an advanced lilypond users, I can categorically assert that
> lilypond is not trying to be 'clever'. This is an utter
> misunderstanding. Lilypond is however trying to engrave music to the
> highest possible standard, and this is an immensely difficult
> programming proposition, hence the complexity under the hood, and the
> slight difficulties in the syntax. It's not meant to be simplistic or
> easy like ABC.

I hate to waste a good defense, but you are talking about its internals
here and Robert was arguing about the input layer with me.  Different
beasts.  It's akin to discussing plain TeX vs LaTeX based on the quality
of the output.  The point of LaTeX is to provide an input and
abstraction layer, the typesetting remains the job of TeX, the program.
Now LaTeX is indeed bleeding complexity when you poke it too hard.

LilyPond's input language is intended to be expressive and convenient
but a whole lot of pain goes into assuring that it bleeds in concordance
with both reasonable and unreasonable expectations even when you poke it
too hard.

As an example, compare the 2.19 version and interaction of of #{ ... #},
$, and # with the 2.12 one.  The current version is quite "cleverer",
going to large pains to make sure that closures, error messages and
whatnot reliably point to where you'd expect them to be.  This is a much
more thorough layer than LaTeX provides around TeX, and yet people feel
much more comfortable using LaTeX than plain TeX.  The LaTeX layers fall
apart when problems occur and you have to debug.  LilyPond layers tend
to hold up even under debugging.

Robert may be speaking from experience, but experience without actual
knowledge can win over knowledge only when that knowledge in return is
lacking significant amounts of experience.

And I'd argue that dismissing my experience in designing, managing,
maintaining, and explaining complex systems as insignificant does not
likely make for the best fitting working hypothesis.

-- 
David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Andrew Bernard]

Hello Robert,

Speaking as a programmer myself with over forty years of experience, and an
advanced lilypond users, I can categorically assert that lilypond is not
trying to be 'clever'. This is an utter misunderstanding. Lilypond is
however trying to engrave music to the highest possible standard, and this
is an immensely difficult programming proposition, hence the complexity
under the hood, and the slight difficulties in the syntax. It's not meant
to be simplistic or easy like ABC.

Music notation itself is a complex abstraction refined over hundreds of
years. It does not 'leak'.

If you are not happy with the system, and it seems it does mot match your
expectations of what a domain specific language should be like for music,
it may be that you simply need to add ornaments such as cut to ABC, given
that the safe mode in lilypond won't allow you to achieve what you want in
a web app.

To give you a bit of context, David Kastrup is one of the principal ongoing
developers of lilypond and few people have the in depth knowledge of the
internals that he does. He is well aware of the various infelicities we
have, but they are generally being worked on continously. As for lilypond
breaking, I do massively complex New Complexity scores with many code
extensions I wrote in Scheme, and I hammer the software all day long, and I
can't break it, even when stretched to the limits. A testimony to the
fundamental good underlying design and architecture. Most others have the
same experience.

As a final remark, I have learned ABC over the last two days in order to
help you out. It seems to me that it is better suited to Irish music tune
notation, having just enough expressivity to set thousands of tunes.
Lilypond is capable of it, but it is a big machine, and probably like
killing a mosquito with a B 52 bomber. Given the near universal adoption of
ABC by Irish players, I'm surprised nobody has created the Larsen ornaments
for ABC - but then, notating precise ornaments in that music is probably
more for academic analysis and comparison purposes than for session playing.

Andrew



On 18 April 2018 at 05:15, Robert Hickman  wrote:

> > Trying to understand LilyPond syntax based on how
> > it actually processes input is not likely to make learning easy since a
> > lot of complicated mechanisms work behind the scenes in order to make
> > things look easy.
>
> In my general experience, systems which try to be cleaver and are not
> explicit about what they are doing tend to break in weird, unexpected
> ways. Complex abstractions always leak. It is also a constant burden
> on the user if they have to remember that some things are added
> implicitly.
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Consistent vertical alignment of annotations, disable time signiture

[David Kastrup]

Robert Hickman  writes:

>> Trying to understand LilyPond syntax based on how it actually
>> processes input is not likely to make learning easy since a lot of
>> complicated mechanisms work behind the scenes in order to make things
>> look easy.
>
> In my general experience, systems which try to be cleaver and are not
> explicit about what they are doing tend to break in weird, unexpected
> ways. Complex abstractions always leak. It is also a constant burden
> on the user if they have to remember that some things are added
> implicitly.

It turns out I have some bits of specific experience with LilyPond and
its design and its users in addition to non-trivial amounts of general
experience to rely on.

It may save you some headaches to just trust me on that.

-- 
David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

> Trying to understand LilyPond syntax based on how
> it actually processes input is not likely to make learning easy since a
> lot of complicated mechanisms work behind the scenes in order to make
> things look easy.

In my general experience, systems which try to be cleaver and are not
explicit about what they are doing tend to break in weird, unexpected
ways. Complex abstractions always leak. It is also a constant burden
on the user if they have to remember that some things are added
implicitly.

On 17 April 2018 at 17:43, David Kastrup  wrote:
> Robert Hickman  writes:
>
>>> That's not Lisp/Scheme syntax but LilyPond syntax.  There is a
>>> manual for it.  Several, in fact.
>>
>> I'm aware.
>>
>> \context {
>>   \Staff
>>   \omit TimeSignature
>> }
>>
>> If I'm understanding this correctly, this would be written something
>> like the following in a typical OO syntax:
>>
>> x =  Staff.clone();
>> x.omit(TimeSignature);
>
> And
>
> currentlayout.set (x.name, x);
>
> or something when the above appears in
>
> \layout { ... }
>
> Though \omit TimeSignature is short for the music expression
>
> \override TimeSignature.stencil = ##f
>
> and is translated into the identical looking context modification by
> some hook function.  Trying to understand LilyPond syntax based on how
> it actually processes input is not likely to make learning easy since a
> lot of complicated mechanisms work behind the scenes in order to make
> things look easy.
>
> --
> David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[David Kastrup]

Robert Hickman  writes:

>> That's not Lisp/Scheme syntax but LilyPond syntax.  There is a
>> manual for it.  Several, in fact.
>
> I'm aware.
>
> \context {
>   \Staff
>   \omit TimeSignature
> }
>
> If I'm understanding this correctly, this would be written something
> like the following in a typical OO syntax:
>
> x =  Staff.clone();
> x.omit(TimeSignature);

And

currentlayout.set (x.name, x);

or something when the above appears in

\layout { ... }

Though \omit TimeSignature is short for the music expression

\override TimeSignature.stencil = ##f

and is translated into the identical looking context modification by
some hook function.  Trying to understand LilyPond syntax based on how
it actually processes input is not likely to make learning easy since a
lot of complicated mechanisms work behind the scenes in order to make
things look easy.

-- 
David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

> That's not Lisp/Scheme syntax but LilyPond syntax.  There is a manual for it. 
>  Several, in fact.

I'm aware.

\context {
  \Staff
  \omit TimeSignature
}

If I'm understanding this correctly, this would be written something
like the following in a typical OO syntax:

x =  Staff.clone();
x.omit(TimeSignature);


On 17 April 2018 at 16:40, David Kastrup  wrote:
> Robert Hickman  writes:
>
>> Thanks, I have a vague familiarity with lisps, but have never used scheme.
>>
>> I'm not certain how to visually parse a statment like \Staff \omit
>> TimeSignature. It kind of looks like \Staff is a function taking two
>> arguments, where \omit is either a constant or a function that returns
>> a constant, and TimeSignature is some kind of constant. But it could
>> also be that TimeSigniture is being passed to \omit, which returns to
>> \staff. It's difficult to read because it doesn't parenthesise like
>> typical programming languages.
>
> That's not Lisp/Scheme syntax but LilyPond syntax.  There is a manual
> for it.  Several, in fact.
>
> \context {
>   \Staff
>   \omit TimeSignature
> }
>
> is a context definition that starts by copying the existing "Staff"
> context definition and adds an omission of the stencil for the
> TimeSignature grob (graphical object) to it, then takes this as a new
> context definition.  Since this copies the original "\name Staff"
> definition of the origin Staff definition, it overrides the existing
> Staff definition.  If you specified a different name, it would instead
> create a new context definition under the given name.
>
> I am not enthused with that syntax either.
>
> --
> David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[David Kastrup]

Robert Hickman  writes:

> Thanks, I have a vague familiarity with lisps, but have never used scheme.
>
> I'm not certain how to visually parse a statment like \Staff \omit
> TimeSignature. It kind of looks like \Staff is a function taking two
> arguments, where \omit is either a constant or a function that returns
> a constant, and TimeSignature is some kind of constant. But it could
> also be that TimeSigniture is being passed to \omit, which returns to
> \staff. It's difficult to read because it doesn't parenthesise like
> typical programming languages.

That's not Lisp/Scheme syntax but LilyPond syntax.  There is a manual
for it.  Several, in fact.

\context {
  \Staff
  \omit TimeSignature
}

is a context definition that starts by copying the existing "Staff"
context definition and adds an omission of the stencil for the
TimeSignature grob (graphical object) to it, then takes this as a new
context definition.  Since this copies the original "\name Staff"
definition of the origin Staff definition, it overrides the existing
Staff definition.  If you specified a different name, it would instead
create a new context definition under the given name.

I am not enthused with that syntax either.

-- 
David Kastrup

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

Thanks, I have a vague familiarity with lisps, but have never used scheme.

I'm not certain how to visually parse a statment like \Staff \omit
TimeSignature. It kind of looks like \Staff is a function taking two
arguments, where \omit is either a constant or a function that returns
a constant, and TimeSignature is some kind of constant. But it could
also be that TimeSigniture is being passed to \omit, which returns to
\staff. It's difficult to read because it doesn't parenthesise like
typical programming languages.

On 17 April 2018 at 01:57, Andrew Bernard  wrote:
> Hi Robert,
>
> As I mentioned and others have said, there is no substitute for studying the
> NR and the Learning Manual, in detail, exhaustively. It's a powerful program
> with enormous control, unlike typical GUI programs. It's no different to
> learning to play tin whistle. Nobody would expect to learn it in a week.
> Because lilypond is text based, you have to fully understand the syntax and
> semantics for advanced work. If you are keen, you can learn Scheme and
> program functions and extensions. The documentation is exceptionally good,
> given that this is open source software.
>
> [Re the Larsen ornaments, I can't see how to integrate Scheme and Lilypond
> in safe mode. Possibly impossible!]
>
> cheerio!
> Andrew
>
>
> On 17 April 2018 at 04:50, Robert Hickman  wrote:
>>
>>
>> I'm finding it quite difficult to find out how to do what I want to do
>> with lilypond.
>>
>

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Andrew Bernard]

Hi Robert,

As I mentioned and others have said, there is no substitute for studying
the NR and the Learning Manual, in detail, exhaustively. It's a powerful
program with enormous control, unlike typical GUI programs. It's no
different to learning to play tin whistle. Nobody would expect to learn it
in a week. Because lilypond is text based, you have to fully understand the
syntax and semantics for advanced work. If you are keen, you can learn
Scheme and program functions and extensions. The documentation is
exceptionally good, given that this is open source software.

[Re the Larsen ornaments, I can't see how to integrate Scheme and Lilypond
in safe mode. Possibly impossible!]

cheerio!
Andrew


On 17 April 2018 at 04:50, Robert Hickman  wrote:

>
> I'm finding it quite difficult to find out how to do what I want to do
> with lilypond.
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Consistent vertical alignment of annotations, disable time signiture

[Thomas Morley]

2018-04-17 0:24 GMT+02:00 Thomas Morley :
> 2018-04-16 23:23 GMT+02:00 foxfanfare :
>
>> *OMG, my first comment which isn't aimed to ask for help but "try" to help
>> someone else :-)
>
> lol
>
> More seriously, your help is very appropriated!

Forgive me, this should read "very appreciated"
Non-native-speaker here...

>
> Best,
>   Harm

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Thomas Morley]

2018-04-16 23:23 GMT+02:00 foxfanfare :

> *OMG, my first comment which isn't aimed to ask for help but "try" to help
> someone else :-)

lol

More seriously, your help is very appropriated!

Best,
  Harm

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

Re: Consistent vertical alignment of annotations, disable time signiture

[foxfanfare]

Robert Hickman wrote
> Works correctly, I found variations on the following with google, which
> was
> giving a syntax error:
> 
> \context { \Staff \omit TimeSignature}

If I understood correctly, this syntax is good, but works for the layout
block as a "global" preset.

\omit Staff.TimeSignature should be placed in the "score" block as something
you may want to revert in some point.

*OMG, my first comment which isn't aimed to ask for help but "try" to help
someone else :-)



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Simon Albrecht]

On 16.04.2018 20:50, Robert Hickman wrote:

\omit Staff.TimeSignature

Works correctly, I found variations on the following with google, 
which was giving a syntax error:


\context { \Staff \omit TimeSignature }

I'm finding it quite difficult to find out how to do what I want to do 
with lilypond.


That’s why, as IIRC the website points out quite clearly, we always 
speak of the Learning Manual as a must-read. And that means sequentially 
and thoroughly, maybe more than once. True, getting started with 
LilyPond is hard at times, but if you follow that route, many 
frustrations will be saved. And of course I do think the effort is worth 
it :-)


Best, Simon

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

\omit Staff.TimeSignature

Works correctly, I found variations on the following with google, which was
giving a syntax error:

\context { \Staff \omit TimeSignature}

I'm finding it quite difficult to find out how to do what I want to do with
lilypond.




On 16 April 2018 at 19:43, Malte Meyn  wrote:

>
>
> Am 16.04.2018 um 20:39 schrieb Simon Albrecht:
>
>> On 16.04.2018 20:05, Robert Hickman wrote:
>>
>>> So far I have the result attached, which is close to what I want, but I
>>> haven't found a clear example of how to get the two text annotations to
>>> align vertically.
>>>
>>
>> Try overriding TextScript.staff-padding – which will also move them up at
>> appropriate values.
>>
>> I'd also like to move both up a bit.
>>>
>>> I'd also like to remove the time signature as it isn't needed in this
>>> example.
>>>
>>
>> That’s easy: \omit TimeSignature ;-)
>>
>
> Depending on where this is placed, it has to be
>
> \omit Staff.TimeSignature
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Consistent vertical alignment of annotations, disable time signiture

[Malte Meyn]

Am 16.04.2018 um 20:39 schrieb Simon Albrecht:

On 16.04.2018 20:05, Robert Hickman wrote:
So far I have the result attached, which is close to what I want, but 
I haven't found a clear example of how to get the two text annotations 
to align vertically.


Try overriding TextScript.staff-padding – which will also move them up 
at appropriate values.



I'd also like to move both up a bit.

I'd also like to remove the time signature as it isn't needed in this 
example.


That’s easy: \omit TimeSignature ;-)


Depending on where this is placed, it has to be

\omit Staff.TimeSignature

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

Re: Consistent vertical alignment of annotations, disable time signiture

[Simon Albrecht]

On 16.04.2018 20:05, Robert Hickman wrote:
So far I have the result attached, which is close to what I want, but 
I haven't found a clear example of how to get the two text annotations 
to align vertically.


Try overriding TextScript.staff-padding – which will also move them up 
at appropriate values.



I'd also like to move both up a bit.

I'd also like to remove the time signature as it isn't needed in this 
example.


That’s easy: \omit TimeSignature ;-)

Best, Simon

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