[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distance of a grob from its reference point

From: Paolo Prete
Subject: Re: Distance of a grob from its reference point
Date: Wed, 15 Jan 2020 22:21:26 +0100

Hi Aaron,

I apologize too if I'm going to use words that can appear a bit rude. This is only for making the goal clearer, and I state again that without your great help I could not do my editor.
Now: there's a misunderstanding in your reply too.
I'm not focusing on the *manual* tweaking. The opposite is true: I'm focusing on the *automatic* tweaking. 
It appears to me that you all are convinced that I want to bypass this Lilypond feature in order to make a WYSIWYG editor.
That's absolutely false. WYSIWYG editors are IMHO too much time consuming. Then I want to put in my editor the automatic algos of Lilypond. X/Y-offset is one of them. I'm not interested in *manual* shifting the brackets. My editor already does that with the extra-offset properties, and it works. Instead, I'm focusing on the automatic placement of the other near objects as a consequence ("avoid collisions method"). Doing that manually is very tedious and I want to avoid it.
Don't interpret the thread as a "automatic vs manual placement method*; instead see it as "automatic 1) vs automatic 2) placement".

In addition: you say that you disagree that everyone has to do fine tuning. I think that the important thing is to make not me or you to do fine tuning. The important thing is to allow *Lilypond* to make it, if required.
It would be really a waste that a so wonderful tool can't accomplish that only because a dummy value is not pulled out. 
Without a proper behavior of the "\offset" command you cannot do nor the automatic 2) placement, nor a fine tuning.


It seems

  (I apologize if that
is coming across sarcastically, but I am afraid I lack better

On Wed, Jan 15, 2020 at 4:50 AM Aaron Hill <address@hidden> wrote:
On 2020-01-14 7:10 pm, Paolo Prete wrote:
> On Tue, Jan 14, 2020 at 9:08 PM Aaron Hill <address@hidden>
> wrote:
>>  I am not connected to the world of modern notation, but I
>> cannot envision any musical meaning for the exact vertical position of
>> an OttavaBracket.
> This is not true. There are many and many cases in which you need to
> tune
> the position of the ottava bracket as well as any other bracket.
> And I'm not talking about modern notation. Even in nineteenth century
> notation this is absolutely necessary.
> The first obvious example is when you have slurs near brackets. Which
> happen *very frequently*
> In this cases a common algo is to:
> 1) choose which of the two objects has to be placed above (there's not
> a
> rule for that: it depends on aesthetical choices)

That was what I suspected.  This is aesthetics, not semantics.  The
vertical position of a bracket carries no musical intention; unlike how
the vertical position of a note head relates to pitch.  In my mind,
LilyPond syntax is largely about communicating the musical content and
letting the software deal with putting the right ink on the page in the
right spot.

That is not to say that aesthetics does not matter, and LilyPond should
strive to meet what is generally considered good and pleasing to the
eye.  But in order for aesthetics to be codified, one just needs to
surface all of the important aspects and constraints, and it sounds like
LilyPond does not yet have that level of information.  As such, you are
finding it necessary to step in and shift things around.

Side note: I should be clear that I am not "against" the prospect of
manual tweaking tools.  Even if it were just your life that was made
easier--and it is clear you are not the only one who would benefit--then
such tools are justified.  But my view and practice of software
engineering is largely focused on automation and getting the computer to
do the heavy lifting.  I dislike manual tweaking, as I have wasted away
many hours on such details.  For my own sanity and productivity, I have
to restrain myself.  As such, I very much need LilyPond to be able to
make the smart decisions on my behalf.  That is why I am trying to
defend getting the automatic parts working better; but I need to be more
mindful to not hinder progress on the manual parts.

> 2) move them according to decision 1) and then *tune* their coordinates
> (which is tedious even with WYSIWYG editors, and requires
> trial-and-error
> even with them!).
> Please note that you can't simply say: "ok, let's move this up and this
> down and all is done". You have to make heavy micro-tuning as a
> consequence.

I would disagree with the notion that everyone has to do fine tuning.  I
certainly do nothing of the sort in my work, but I do not work on the
same type of projects.  My needs and requirements are quite likely much
less strict.  When it comes to the matter of manual tweaking, my use
cases are largely irrelevant.  I should, therefore, really bow out of
this conversation as I am not the target audience and am probably doing
a better job of muddying the waters.

-- Aaron Hill

reply via email to

[Prev in Thread] Current Thread [Next in Thread]