Re: A snippet for editing curves using the mouse and reporting changes to the .ly file

[Flaming Hakama by Elaine]

---------- Forwarded message ----------
> From: Urs Liska <address@hidden>
> To: address@hidden
> Date: Mon, 16 Dec 2019 10:18:36 +0100
> Subject: Re: A snippet for editing curves using the mouse and reporting
> changes to the .ly file
> Hi Paolo,
>
> I have followed the discussion but didn't have the time to actually test
> your code until today.
>
> First of all let me state that this is really great, and when I will
> raise some issue these are in no way meant as critique. I really want to
> see this integrated in the toolbox in one way or another, but there are
> a few minor and major questions that should be answered before.
>
> Regarding integration in Frescobaldi I agree that it's appropriate to
> create an independent version of the code and then have Frescobaldi deal
> with it.
>
> Generally I'd say this functionality should be integrated in LilyPond
> itself, and I hope we'll find a version that satisfies all potential
> questions.
> What Werner Lemberg hinted at when mentioning my name was that we could
> alternatively or additionally include the snippet in the openLilyLib
> package oll-misc (https://github.com/openlilylib/oll-misc/). While I
> prefer having it in LilyPond proper you should understand that any
> addition we do now will most surely *not* be included in the next stable
> release 2.20 but will only be available through the next development
> version. Judging from recent history version 2.22 may be quite some way
> in the future.
> For me this won't be an issue since I'm always using the development
> version, but if we want this functionality to be generally available we
> might better include it in LilyPond itself and then *additionally* to
> openLilyLib.
>
> Now to the functionality itself. Again, the length of the list of
> comments should not diminish my excitement about your code!
>
>   * For integration in LilyPond the functionality should be wrapped into
>     a single file that can be included. Including the file should
>     automatically activate the functionality.
>     Maybe there should be a second includable file that does *not*
>     automatically activate the functionality but provides a command to
>     selectively switch it on and off or apply it to only one curve.
>     There may be people who don't want the whole score to be polluted
>     with the control points but only see the slur they want to edit.
>   * The behavior of the script in the SVG file is too intrusive IMHO.
>       o forcing the interface with the pop-up prevents any external
>         contexts (like e.g. Frescobaldi) from accessing the
>         functionality in the way they need to. There should be some way
>         to interact with the data in a different way. Also, it should be
>         possible to get to the raw data instead of the formatted \shape
>         command string.
>       o It seems the function prevents point-and-click from working. I
>         assume this is related to your decision to “hijack” the context
>         menu functionality.
>       o If that's correct (or even if not) I think the context menu
>         should not be blocked in this way. Probably it's a better
>         approach to *add* an entry. Maybe this is also a usable hook for
>         external programs to integrate your function.
>   * There is one flaw in the behaviour: When you include the generated
>     \shape command in the score and recompile the modified slur is drawn
>     correctly (which is totally great!). However, when you now modify
>     that slur again (which is a very reasonable expectation) the \shape
>     command is now calculated relatively to the already-applied \shape,
>     so *now* the recompilation will produce a totally unexpected result.
>     I see two possible solutions:
>       o Somehow determine if a \shape has already been applied to the
>         slur and consider the values when generating a new \shape. I
>         have no idea whether this is possible.
>       o Don't use  \shape at all but finally integrate \shapeII into
>         LilyPond and use it for the graphical tweaking. With \shapeII it
>         is possible to much more robustly shape a slur than with \shape,
>         and it is somewhat more absolute. I've attached the
>         documentation PDF, and you can find the code at
>
> https://github.com/openlilylib/snippets/tree/master/notation-snippets/shaping-bezier-curves/shapeII
>         (don't let the warnings scare you when compiling the example file).
>         There would be some figuring out how to best apply the function,
>         starting from the approach of polar coordinates, I'd say.
>         To make it work, the function would have to do some more
>         calculations that simply measuring the offsets, but I'm
>         convinced it would be more than worth the effort.
>
> Best
> Urs
>
> Am 16.12.19 um 03:42 schrieb Paolo Prete:
> > Hello,
> >
> > the snippet attached to this mail allows the tuning with the mouse of the
> > curves generated by Lilypond so that the changes can be reflected on the
> > original .ly file.
> > The tuning is done on the generated SVG file, as explained in this thread
> > (but you can look at the code of the attached file, there's a mini how-to
> > and it's very simple to use):
> >
> > https://lists.gnu.org/archive/html/lilypond-user/2019-12/msg00217.html
> >
> > Since the snippet is incompatible with Lilypond 2.18 it cannot be
> included
> > in the snippets repository of that version, as explained by Thomas (it
> > would be bad to downgrade the code).
> > Is it possible to include it in the development version, then?
> >
> > (I also ask Aaron to revise the indentation / length of lines of the
> Scheme
> > code)
> > The snippet has had very positive feedbacks, and should not be left
> without
> > a future, IMHO. I believe it can define a template for the tuning of many
> > other properties of graphic objects, in a very simple way both for the
> > Lilypond user and for those who want to extend the procedure through
> > Javascript.
> >
> > In the Lilypond user ml they suggested to include it in Frescobaldi or
> > Denemo; but I don't think it's the best solution. Because, being the
> > snippet 100% lilypond native code, it does not need any additional tool
> to
> > work, and demonstrates the potential of Lilypond in generating
> interactive
> > SVG. To be more precise, given that it is 100% Lilypond, Frescobaldi and
> > Denemo should recognize it automatically.
> > It is also true, as Carl states, that LilyPond is not intended to be a
> > WYSIWYG software; but I believe that the "tuning" through GUI is not
> > opposed to this vision but integrates it, especially considering that the
> > GUI is generated by Lilypond itself.
> >
> > Best,
> > Paolo



Like Urs, I hope my comments are not taken as any kind of criticism.
This is amazing work, and I'm just hoping to contribute to making it better.



While the approach of including the JavaScript as CDATA has been shown to
work, I wonder if that is the best way to do it.  The main issue being, you
can't just write any old JavaScript, since it is nested within a double
quote, so you have to avoid use of double quotes (or escape them).

Even within this current approach, I'd prefer to see the JavaScript code in
a separate .js file, and included via \include.  That would make it clearer
that the code is in fact JavaScript, and let anyone who might want to edit
it take advantage of syntax highlighting.


But the CDATA approach seems like a non-ideal way to link things together.
Especialy since SVG lets you include JavaScript by referencing an external
file, why not just publish the JavaScript in a file, then reference that
file from the SVG?

Ideally, if this were to be the beginnings of a framework to allow
scripting in SVG files, we could have a command line argument that
specifies a script location, and it would add that reference in the SVG.
 (For this particular feature, perhaps the feature's flag would know the
default JavaScript file and include that.)



Regarding the behavior of the script in the browser, I agree that there
could be other ways of delivering the Shape data.  I'm not sure that pure
SVG will allow these, so we might have to use an HTML document that
includes the SVG, as well as other elements.   Which would also allow
multiple SVGs to be edited in the same document.

I'm not sure what the issue is with pop-ups that Urs mentioned.
Philosophically, I agree that overriding the right-click default menu is
not ideal.  But I'm not sure quite why it is a dealbreaker in terms of
integration with other apps like Frescobaldi.

Here are some alternative ideas.

Assuming we leave the right-click behavior, the popup could include a
button that says "Save", and clicking it could append the Shape
modification text to some other element on the page, or log it to the
console, or save it to a data object or to local storage.  For the
data-based versions, there could be another button, perhaps located in a
control panel in the header, footer, left or right column, or in a popup,
that could display the mods in another element and/or copy to clipboard.

If we don't like the right-click behavior, this same idea of presenting a
"save" button could be added to the initial drag behavior, eliminating the
need to right-click and override the default menu.  Or, the button could be
located in the control panel, and would be aware of what the currently
selected shape is.


The other main feature that would make this absolutely killer would be to
have a way to connect the mods with the source code.  Seems like the
weakest point of the current workflow is identifying the place in the
source code which shape is being modified, then manually cutting/pasting.

In my mind, the ideal approach would be for every shape to have an ID, and
then the shape mod could reference the ID.  Then you could just load your
mods in one place (either inline, or in an included file.)

I suspect that the closest thing we have is the OLL, which allows you to
specify mods based on timestamp.

I understand that a pure lilypond solution is ideal, and therefore using
OLL is not ideal,  But, OLL does already exist as a framework for exactly
these kind of separate-presentation-from-content issues, so it seems worth
exploring.

So, the question becomes, is it possible to include in the SVG elements the
timestamp?  If so, then it would be possible to format the Shape mod as an
OLL directive, where we read the timestamp address from an attribute.

The workflow would become: 1) Run the SVG (or HTML) document in the
browser. 2) Edit shapes, and for each one you like and want to apply, click
the "save" button. (maybe we also need a "delete mod" button by each entry,
in case you change your mind)   3) When you are done editing shapes, click
a "show all mods" button that displays the mod text in an element or popup.
 4) Copy the list of mods from the element and paste them into your OLL
overrides file.


If any of these UI suggestions are welcome, I can work on the JavaScript
side of it.



Regarding re-indenting the scheme code, here is my attempt:

\version "2.19.45"

% lily-easy-slurs.ily

showControlPoints = #(grob-transformer 'stencil
    (lambda (grob orig)
        (define (draw-control-point pt)
            #{ \markup \translate $pt \with-color #red \draw-circle #0.35
#0 ##t #}
        )
        (define (draw-control-segment pt1 pt2)
            (let
                ((delta
                        (cons
                            (- (car pt2) (car pt1) )
                            (- (cdr pt2) (cdr pt1) )
                        )
                ))
                #{ \markup \translate $pt1 \with-color #'(1 .5 0)
\draw-line $delta #}
            )
        )
        (let*
            (
                (pts (ly:grob-property grob 'control-points))
                (dots
                    (map
                        (lambda (pt) (grob-interpret-markup grob
(draw-control-point pt)))
                        pts
                    )
                )
                (lines
                    (map
                        (lambda (pt1 pt2) (grob-interpret-markup grob
(draw-control-segment pt1 pt2))
                    )
                    pts
                    (cdr pts)
                )
            )
        )
        (ly:stencil-add
            (apply ly:stencil-add lines)
            (apply ly:stencil-add dots)
            orig)
        )
    )
)

\layout {
    \context {
        \Voice
        \override PhrasingSlur.stencil = #showControlPoints
        \override PhrasingSlur.output-attributes = #'((class .
"lilySlur")(slurtype . "PhrasingSlur"))
        \override Slur.stencil = #showControlPoints
        \override Slur.output-attributes = #'((class . "lilySlur")(slurtype
. "Slur"))
        \override Tie.stencil = #showControlPoints
        \override Tie.output-attributes = #'((class . "lilySlur")(slurtype
. "Tie"))
    }
}


HTH,

Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
address@hidden
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-