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