lilypond-devel
[Top][All Lists]
Advanced

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

Re: How to proceed


From: David Kastrup
Subject: Re: How to proceed
Date: Tue, 16 Oct 2012 02:44:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Joram Berger <address@hidden> writes:

> sorry for joining the discussion too late (I joined the mailinglist just
> now).

There is all the time of the world for this discussion now.

> In short: I would be very fond of a syntax like (no # or')
> \set context.property = 0.3
> \unset context.property
> and a unification of \set and \override.

[...]

> I am still (after using LilyPond for years) a bit confused why the
> settings need all those # and ' and spaces (especially the ') and in
> which order to put them (I often copy-paste because I can't remember
> such settings by heart).
>
> I am very excited about LilyPond, so I will take any effort to find the
> code needed for my scores. But I have introduced LilyPond to several
> musicians to whom any programming (e.g. the python syntax) is a mystery.
> And they really have a hard time to get it working. The basic syntax is
> great and easily learned (like a4-.( c2.) r1), but anything that is not
> available as \command but has to be changed via scheme code is out of
> reach for many users. The difference of all those \set, \override,
> \tweak commands is also not transparent to me.
>
> Would a syntax like:
> Staff.size = 18
> Staff.color = red
> or
> \tweak style = slash (or style = 'slash' if that is more consistent)
> be possible? That would be something I could remember and teach to music
> students.

Most of the things that would count as simplifications are so because
they drop details used for distinguishing things told to the computer.
Where those distinctions are distinctions between non-sensical
directions and potentially useful directions, dropping them means that
LilyPond needs dependable ways to tell non-sense from sense.  That means
that before being able to drop such a distinction, sense and non-sense
need to be separated by lines that are clearly distinguishable by
LilyPond and clearly recognizable to the user.  Usually this means that
they obey simple rules.

Searching and recognizing those rules and condensing them into a
coherent design needs significantly different analytical skills than
having an opinion about simplicity, even though this opinion may very
well correlate with some degree of underlying consistency.

And there will be situations which lend themselves to multiple
incompatible patternings.  Picking among different incompatible
patternings of a problem space means making choices with consequences
for future patterning work beyond the immediately apparent consequence
of each choice.

A coherent set of choices governed by a particular patterning may be
called "design".  Letting choices be made individually by a democratic
process will favor varying concepts of simplicity on a detail level
while breaking the ability for creating a design according to a
pervasive patterning of the problem space.

Simple is hard.

> In short: It's great that advanced users can change most everything
> with scripting code. However, I would suggest to have the basic
> functionality usable for beginners and musicians who don't know
> programming.

What I am getting at is that if we want to have the basic functionality
usable for beginners and musicians who don't know programming, it won't
do to let beginners and musicians who don't know programming make the
design choices, even though their input and feedback will be helpful for
making checking that the design actually meets its objectives.

> Frescobaldi does a great job in this direction and I'm looking forward
> to GLISS results.

I am not convinced that we have found processes yet which favor arriving
at good solutions.  Frescobaldi, according to my impression not actually
based on any actual experience, is a one-person project from its
decision structure, based on the feedback of a user community.

GLISS, as I understand it, is focused on a democratic decision-making
process.  When the underpinnings of the issue at hand are complex enough
to cease being accessible to the decision-making public, simple choices
based on the ability to present populistic toy simplifications of
problems prevail.

We see this process in politics where concepts like "reduce federal
deficits by cutting taxes" are actually winning strategies since who
would not want to reduce the federal deficit, and who would not want to
cut taxes?  Do a vote on both issues, and you'll easily get a "yes" on
both accounts.  The problem is that they belong to mutually incompatible
patternings of the federal finances.

> I will add some ideas there and hope for the best.

And I think that is likely the best you can do.

Welcome to the list.

-- 
David Kastrup




reply via email to

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