lilypond-devel
[Top][All Lists]
Advanced

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

Re: A snippet for editing curves using the mouse and reporting changes t


From: Paolo Prete
Subject: Re: A snippet for editing curves using the mouse and reporting changes to the .ly file
Date: Tue, 17 Dec 2019 05:08:09 +0100

In response to Elaine and Urs

1) I already thought about the way to automatically feedback the
modifications to the original .ly file, instead of the alert() string.

Again, it will be 100% JS + SVG. Just have a little patience ;-)
Basically, Lilypond will have to import the original .ly code as the value
of some property of a  dummy node <g> at the end of the <svg> tree, in the
way Aaron made for the previous snippet.
Then with JS I can modify the content of this big string, and save back a
modified file

https://stackoverflow.com/questions/23218174/how-do-i-save-export-an-svg-file-after-creating-an-svg-with-d3-js-ie-safari-an

2) About linking an external js script, instead of the whole content of the
code: you can already do that, just follow the answer of Aaron to my
question:

https://lists.gnu.org/archive/html/lilypond-user/2019-12/msg00251.html

However, this approach is useless for now. The code is not mature for
providing an external lib. I still have to define the general template for
this feature (as you see, there are fixed functions: initGrob(),
selectGrob(), moveGrob()... )

I suggest to test at least three snippets for different properties (I just
created the second one). All the rest will follow as a natural consequence.

Best,
P


On Tue, Dec 17, 2019 at 3:05 AM Flaming Hakama by Elaine <
address@hidden> wrote:

> ---------- 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
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>


reply via email to

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