>
> Both lilypond and LaTeX have steep learning curves
One of the conditions of the package
, in my mind,
is to make
its
usage possible at
the
highest
level, but configurable at the lowest.
LaTeX is such a powerful utility, and in this case should really extend
our workflows (and not necessarily further complicate them).
It's nearly there, but at this point, for example,
\documentclass{article}
\usepackage{scholarLY}
\begin{document}
\annotations{lilypondexportfile.inp}
\end{document}
will render the entire list (well, virtually; the file paths are a little
wonky rn). We've recently added a default stylesheet that is itself used by
the package to format the list, but also exemplifies almost all of the
macros available for customization. So it's definitely a priority for this
to be as practical a resource as possible.
Also, we plan to add more export types (such as markdown, and even scheme -
which could make compilation possible directly in lilypond), so that the
choice of *how* it is implemented is itself available upfront.
On Wed, Jun 29, 2016 at 10:03 AM, Urs Liska <u...@openlilylib.org> wrote:
>
>
> Am 29.06.2016 um 15:12 schrieb Paul:
> > Hi Jeffrey,
> >
> > It's good to hear about your progress! Just a thought about modes...
> >
> > On 06/27/2016 07:50 PM, Jeffery Shivers wrote:
> >> ***Final/"draft" Modes***
> >> OpenLilyLib will ideally be used in final/draft/etc. modes in order to
> >> toggle between fancy/plain settings, or really whatever the user
> >> decides to work out. The idea is to be able to set/compile settings in
> >> either mode at the individual package level (i.e. scholarLY, etc.),
> >> and also to be able to toggle all-at-once by directing OLL's mode. And
> >> individual packages will have an additional optional setting to *keep*
> >> whatever mode regardless of OLL's mode, if so desired.
> >>
> >> The question here is about naming mostly. A `final` mode is ideally
> >> the *implicit* mode, so it doesn't have to be explicitly set (though
> >> it still could be). An alternative mode, `draft` would need to be
> >> turned on explicitly. There have apparently been discussions in the
> >> past particularly about the name "draft" (though I haven't found them
> >> in my search); in any case, I'd like to know what others think about
> >> that now, and of course the concept of this feature in general.
> >>
> >> Looking forward to your thoughts about these things, and to
> >> following-up with some test-drivable results in the near future.
> >
> > For greater flexibility, would it be feasible to allow users to create
> > and name any number of their own modes (rather than having two
> > "hard-coded")? That's probably more complex to implement, but it
> > would allow switching between 3 or more modes for whatever purpose.
> > Again, just a thought...
>
> Interesting thought - although I wouldn't want to decide this
> spontaneously. But maybe some clarification about the implementation is
> helpful for others to think about it.
>
> We're talking about openLilyLib's configuration mechanism.
> ScholarLY is a package that implicitly loads openLilyLib through the
> oll-core package, which in turn implements the configuration
> infrastructure.
>
> Once oll-core is loaded there is a tree structure available holding all
> sorts of options that can be handled using (among others) a \getOption
> and a \setOption command. openLilyLib packages are encouraged to make
> use of that mechanism to provide a consistent user interface across
> openLilyLib packages. But (together with the \registerOption command)
> they can also be used independently by any user file.
>
> Now, switching modes (like with LaTeX's class options) is handled by
> setting a global option in openLilyLib. By itself this does nothing, but
> packages are encouraged to respond to that setting. As an example the
> ScholarLY package might apply coloring of annotated items when "draft"
> mode is active and keep everything black in "final" mode. However, it is
> up the package maintainer if and how the packages handles "modes".
>
> Implementation-wise it is basically nothing to add another mode by
> simply allowing additional values for the "mode" option. Packages can
> also quite easily implement that by extending the conditionals in their
> functions to respond to more than two modes.
> However, to be useful this must be discussed rather on the conceptual
> side, i.e. what kind of mode would make sense and how to propagate that
> through different packages (doesn't make much sense to have a mode that
> doesn't do much).
> So, this aspect is where this discussion should be done.
>
> FWIW, just creating an arbitrary option and configuring your personal
> files to do some configuration based on that option might as well
> provide everything you asked for, without even touching the openLilyLib
> packages themselves.
>
> HTH
> Urs
>
> >
> > Thanks for your good work!
> > -Paul
> >
> > _______________________________________________
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
