Re: Contemporary notation (Re: GSoC projects list)

[Urs Liska]

Am 06.02.2017 um 20:15 schrieb "Jürgen Reuter":
> Hi all,
>  
> personally, I think, it is as always in software development that
> addresses a wide audience: the challenge to find an appropriate level
> of abstraction.
> If you want to support *any* kind of notation, then just use a
> painting or CAD software.  Obviously, you do not want to do that,
> because you will loose any musical semantics, including the
> possibility of reformatting, transposing, or whatever else
> musicologically editing you would like to apply.

Definitely. One strong point for LilyPond is the ability to encode stuff
with semantic meaning, and have the result behave like a regular score
element that adjusts automatically.

>  
> On the other extreme, you would focus on a specialized notation system
> that addresses a selected audience only and is of little or no value
> for other users.
>  
> A common approach is solve this dilemma is to:
>  
> * (1) Focus on a selected set of specialized features that you expect
> to be useful for many users.  Then you can add specialized
> automation.  For example, the abstraction of having objects called
> "notes" that have a particular property called "pitch" enables you to
> group a selection of notes into a "music expression" and "transpose"
> the whole expression by altering the pitch of each note in that group.
>  
> * (2) For exceptional cases, provide more lower-level features, that
> provide less automation due to an increasing lack of musical
> semantics, but are more flexible.  For example, LilyPonds feature to
> embed postscript snippets is extremely flexible.  But it is just
> graphics, without any musicological sementics.  And as such, you can
> not impose any musical operation on it.

Yes, this goes in the direction of what I meant with "building blocks".
Today I found a good example of such low-level functionality that might
make it easier to build upon and create higher-level functionality upon:
One of the things I'm currently investigating is a special form of
slurs, for which I overwrite the stencil and create a shape from
scratch. From the grob that is passed to that callback function it is
possible to get hold of all sorts of information like its properties or
the attached note columns, the objects in the note columns, grob-objects
like stems or flags and many others. But it would make creating such
stencil overrides much easier if one wouldn't have to always look again
for the ways how to retrieve the necessary information and could instead
use a function like, say,

#(define myStencil
  (define-slur-stencil 
    (do-something-with (fourth cps))
...
))

where all relevant information such as control points, bounding note
columns, attached note heads or extremal note heads when it's chords,
and potentially more were simply available.


>  
> Having this approach in mind, I implemented the cluster engraver
> roughly 15 years ago.  Urs, you mentioned creating "notation that
> behaves like a glissando, i.e. any drawn connection between two
> notes."  With the cluster engraver, you (sort of) can do such a
> thing.  The idea was to provide graphical notation that builds upon
> musical expressions by transforming that musical information into a
> corresponding graphical shape.  This way, the cluster engraver fills
> the gap between non-graphical (and therefore specialized) standard
> notation on the one hand and generic, but non-musical low-level
> graphics on the other.  Maybe the cluster engraver would be a proper
> starting point for more music expression based graphical notation?

This should  be noted. I think independently from this GSoC idea I'll
create a dummy package https://github.com/openlilylib/contemporary (not
online yet, but as this message will go into the archives ...) with a
brainstorming Wiki page.

>  
> Another thing, I guess, is making it easy for musicians without
> programming knowledge to smoothly embed their own articulation signs,
> note heads, clefs, and other font symbols into LilyPond at runtime: 
> Just define a new articulation sign or note head shape or clef at the
> top of your .ly file with a single short line of scheme code that
> references some, say, .eps file.  I think, this is still not that
> easily possible, right?  (Please correct me, if I am wrong.)

As replied in another post this is exactly the kind of simplification I
have in mind.

>  
> Personally, I am even not sure of how to properly notate contemporary
> music.  Yes, I have seen e.g. excerpts of Stockhausen's score of his
> Studie II, and Wehinger's aural score of Ligeti's Artikulation, as
> well as a score of Kagel.  (LilyPond's short, long and very long
> fermata signs were actually inspired by this score of Kagel.) Still, I
> am not satisfied with such notation: At least to my perception, it
> typically does not represent well essential nuances of e.g. electronic
> sounds.

Well, there's an abundance of notation today, and - as Jeffery has
pointed out - it would be overwhelming to go for a comprehensive coverage.

>  
> Probably most important, I think you first of all need lots of
> examples to get a sense for what might classify as candidate for an
> appropriate abstraction: Is it all about graphical notation?

No. About *any* extended notation not easily covered by LilyPond yet.

>   Or rather use of individual / personalized font symbols? 

This is another, but definitely non-exclusive aspect.

> What else is useful?  In fact, classification by having seen lots of
> examples is one of our brain's fundamental approaches for recognition...

Of course. But as I've written elsewhere I expect this GSoC project to
be approached (if at all) by a composer with his/her specific needs in
mind. It would then be our responsibility as a community (mediated by
the mentor(s)) to ensure there's a sufficiently generic foundation.

Urs

>  
> Best wishes,
> Jürgen
>  

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org