date:20131210

On Tue, Dec 10, 2013 at 3:31 PM, Richard Shann wrote:

>
> only some people are interested in "everything", many want just their
> own bits of interest.
> Denemo is customizable to a great extent, all menus and palettes can be
> modified; most users will not do so, but it would be possible to create
> specialized versions of Denemo for many different areas of interest.
>
> Richard
>

Agreed. But consider this. One of the things that the Adobe Creative Suite
programs have is customizable workspaces. They have a number of
workflow-specific workspaces (for print production or typography, etc.),
but then they also have workspaces that emulate other Creative Suite
programs so that you can work in one program similarly to another. For
instance, when I use Adobe Illustrator, I can use the "Like Photoshop"
workspace if I'm familiar with that program, or "Like InDesign" if I'm
familiar with it. The workspaces aren't 100% identical, since each has its
own set of tools, but it makes it easier to use. The workspace
customization includes menu options, toolbars and palettes (and perhaps a
couple of other things I can't think of offhand).

Similarly, you could offer the user a "Like Finale" or "Like Sibelius" or
"Like MuseScore" environment. While not identical, a similar logic to how
those palettes/toolbars are constructed could be applied to ease the
learning curve. This would not require specialized "versions," per se, so
much as preconfigured preferences, perhaps?

Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: on marketing

2013-12-10 Thread Richard Shann

On Sat, 2013-12-07 at 13:40 -0500, Carl Peterson wrote:
> On Sat, Dec 7, 2013 at 1:19 PM, Richard Shann
>  wrote:
> On Sat, 2013-12-07 at 18:11 +0100, Joseph Rushton Wakeling
> wrote:
[...]
> 
> 
> 
> I use MuseScore for quick and dirty composition work...I'm not trying
> to make it "pretty," I'm just trying to get it on a page and be able
> to directly manipulate it. I've done that with Finale when I've had
> some version of it installed on my computer. I can do that with
> MuseScore. I tried a couple of times to do it with Denemo and really
> didn't have a good experience. Part of it is the very menu-centric
> approach (too cluttered),

Well, up to now, the menus were there mainly to allow the user to find
out what the keyboard shortcuts were - even things like move the cursor
right have menu entries so that you can find out that right arrow does
this. (In that case you could guess, but move to measure right? ...
staff down ...)
Now we have palettes too, so those that want to click buttons can, and
search facilities for finding commands and short cuts. But there is
still a way to go.

>  but in general, it just wasn't intuitive to me as a GUI. MuseScore
> does well enough for what I do with it. I think that initial
> experience with Denemo can be very overwhelming, particularly if we're
> talking about someone coming from a Finale-like experience. I've used
> Finale and a broad selection of other music tools (both composition
> and production), and Denemo was just...different. MuseScore is
> different from Finale, but it's alike enough to be a much shallower
> learning curve.

yes, I can imagine.

> 
> 
> To bring us back to Marketing, it's well and good to talk about all
> the things that LilyPond or Denemo or Frescobaldi can do that Finale
> and/or Sibelius can't. However, if we're looking at convincing people
> to switch from Finale and/or Sibelius to the LilyPond sphere of
> influence, we have to be able to show them that everything

only some people are interested in "everything", many want just their
own bits of interest.
Denemo is customizable to a great extent, all menus and palettes can be
modified; most users will not do so, but it would be possible to create
specialized versions of Denemo for many different areas of interest.

Richard

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions


Am 10.12.2013 19:46, schrieb David Kastrup:

Urs Liska  writes:


Am 10.12.2013 18:30, schrieb SoundsFromSound:

For whatever it's worth, I've always used unstable builds from about 2 weeks
after I started using LilyPond. I began with stable, but then quickly hopped
on the unstables and have had zero issues with my scores.

I love the bleeding edge, what can I say?:)  I am a risk-taker! lol


Using unstable versions of a program like LilyPond is much less a risk
than using a GUI tool that can crash and wipe away your current work.

There was a time when people lost work using LaTeX on MSDOS in spite of
it being a batch application.

Here was the deal: the syntax to include separately includable files in
LaTeX is

\include{filename}

now sometimes people wrote

\include{filename.tex}

by mistake but that meant that auxiliary information about the file was
written to filename.tex.aux which MSDOS abbreviated to filename.tex.

Very ugly.  Very unexpected.  At some point of time, TeX engines were
changed in order to refuse writing a file under comparable
circumstances.


Interesting case ...

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Embeddable MIDI

2013-12-10 Thread Julien Rioux


Hi,

On 02/12/2013 9:17 PM, Anthony wrote:

Invoking lilypond-book allows me to generate HTML with lilypond tags into
HTML with PNG images. I've got that bit down. But is there a way to embed
the MIDI into the document? Using \midi with generate the midi file but it
doesn't embed it into the HTML document.



There isn't support to embed the midi file, as far as I know. But it 
sounds like a good idea to have that option.



Also, on a less important matter, is there a way to change where and what is
generated? Meaning, I only need PNG images embedded into HTML. But I don't
need eps, tex, texi, ly, ect.


Some of these are needed by various output formats. It does seem odd 
that .tex and .texi files are generated for an HTML doc, though. Did you 
check the command-line arguments to lilypond-book? You can tell it how 
to call lilypond and probably avoid generating the unnecessary files.



Each lilypond snippet seems to go into a
directory XX. Could I change this and put them all into the same directory?



You could do this yourself and change all the hyperlinks to the new 
locations (possibly with a script).


Cheers,
Julien


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions


On Dec 10, 2013, at 9:08 PM, Colin Campbell  wrote:

> On 12/10/2013 06:41 AM, Carl Peterson wrote:
>> On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon  wrote:
>> Hey all,
>> 
>> I recently e-mailed the development list about multiple concurrent 
>> development versions and I’d like to ask users, especially those currently 
>> using the development version, to take the time to respond to a question 
>> regarding the proposal.
>> 
>> If lilypond.org were to propose multiple development versions (say 5 instead 
>> of 1), each offering a different set of experimental features (including the 
>> canonical development version), and if lilypond.org offered information on 
>> which versions were in need of testing by what types of users, would you be 
>> interested in helping out by doing some typesetting with these alternative 
>> versions?
>> 
>> The problem I see is an issue of mixing and matching. What if there is a 
>> feature I want to use on Development Version A and one I want to use on 
>> Development Version B, within the same score? I also foresee a 
>> multiplication of the issues regarding who is using what version on this 
>> list, as in:
>> 
>> Today:
>> 
>> A: "I have this problem. I am using version 2.17.3"
>> B: "We fixed this problem in 2.17.23"
>> 
>> With multiple versions:
>> 
>> A: "I have this problem. I am using version 2.19.A.3"
>> B: "This was fixed on version 2.19.B"
>> A: "Okay, that fixed that, now I have this problem."
>> C: "This was fixed on version 2.19.C"
>> A: "I'm confused. How do I fix both of these problems?"
>> 
> 
> 
> I'm all for exploring options, but I truly believe this adds a level of 
> complexity we can't handle with existing resources and tools, for relatively 
> small gains or potential loss of live testing of beta-level code.
> 
> Cheers,
> Colin

Thanks for all the responses - they are very useful.
It sounds like this is a bad idea.

Cheers,
MS

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to count the number of notes in a .ly file?

"Jan Rosseel"  writes:

> Subject line says it about all. How can I count the number of notes
> present in a .ly file? Or the number of notes in a music expression? 

Number of notes in a music expression would be something like

#(length (extract-typed-music music 'note-event))

If you want to count rests, skips and similar stuff like notes, write
rhythmic-event above.  If a chord should only count once, write
#(length (extract-typed-music '(note-event event-chord)))
in order to stop the extraction at chord level.

> I assume somebody made some (python) script to do this, but I can't
> bring it to the surface with my googling skills... 

That really is a use case where LilyPond's Scheme interpreter makes
things easier than an external script.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

Mike Solomon  writes:

> On Dec 10, 2013, at 6:32 PM, David Kastrup  wrote:
>
>> Refactoring the page building into a stage where its basic operations
>> can be done from Scheme/LilyPond would be a first big step towards being
>> able to experiment with different schemes without recompilation.
>> 
>> The next big step would be to create a modular structure where it is not
>> necessary to replace the page builder for a feature like footnotes, but
>> where you can plug in elements like footnotes by writing code for them
>> and plugging this code into a single, extensible page builder with
>> appropriate interfaces.
>> 
>> Then we can have, without recompilation, tools that provide smarter
>> footnotes, different layouts of them, margin notes and other stuff
>> without interfering with other tools available for the page composition.
>
> I agree that this is a great candidate for refactoring.  I think one
> way to frame the problem would be to imagine that someone wanted to
> take on this task, which is pretty ambitious and would likely require
> a lot of subtasks in extracting out the page breaker.  Each of these
> subtests would require independent verification, and it is likely that
> the entire project could be done separately from the main branch.  It
> would probably require extensive user testing to make sure that all
> the kinks were ironed out.
>
> Let’s say that I set up a version of LilyPond called
> modular-footnote-LilyPond in which I develop this modularity.  How, if
> at all, can users test this before it makes it into the development
> version?

Uh, not really?  That was sort of my point.  Refactoring into extensible
form is a prerequisite to development of features that are not tightly
tied into a particular binary, requiring its recompilation.

But there won't be significant resistance to that kind of work while we
are in the unstable phase of a development version.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

Urs Liska  writes:

> Am 10.12.2013 18:30, schrieb SoundsFromSound:
>> For whatever it's worth, I've always used unstable builds from about 2 weeks
>> after I started using LilyPond. I began with stable, but then quickly hopped
>> on the unstables and have had zero issues with my scores.
>>
>> I love the bleeding edge, what can I say?:)  I am a risk-taker! lol
>>
> Using unstable versions of a program like LilyPond is much less a risk
> than using a GUI tool that can crash and wipe away your current work.

There was a time when people lost work using LaTeX on MSDOS in spite of
it being a batch application.

Here was the deal: the syntax to include separately includable files in
LaTeX is

\include{filename}

now sometimes people wrote

\include{filename.tex}

by mistake but that meant that auxiliary information about the file was
written to filename.tex.aux which MSDOS abbreviated to filename.tex.

Very ugly.  Very unexpected.  At some point of time, TeX engines were
changed in order to refuse writing a file under comparable
circumstances.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Colin Campbell


On 12/10/2013 06:41 AM, Carl Peterson wrote:
On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon > wrote:


Hey all,

I recently e-mailed the development list about multiple concurrent
development versions and I’d like to ask users, especially those
currently using the development version, to take the time to
respond to a question regarding the proposal.

If lilypond.org  were to propose multiple
development versions (say 5 instead of 1), each offering a
different set of experimental features (including the canonical
development version), and if lilypond.org 
offered information on which versions were in need of testing by
what types of users, would you be interested in helping out by
doing some typesetting with these alternative versions?


The problem I see is an issue of mixing and matching. What if there is 
a feature I want to use on Development Version A and one I want to use 
on Development Version B, within the same score? I also foresee a 
multiplication of the issues regarding who is using what version on 
this list, as in:


Today:

A: "I have this problem. I am using version 2.17.3"
B: "We fixed this problem in 2.17.23"

With multiple versions:

A: "I have this problem. I am using version 2.19.A.3"
B: "This was fixed on version 2.19.B"
A: "Okay, that fixed that, now I have this problem."
C: "This was fixed on version 2.19.C"
A: "I'm confused. How do I fix both of these problems?"




From the perspective of a light-duty user and former patch nanny, 
Mike's idea seems quite frankly alarming. The thought of exposing users 
to multiple diverging and possibly incompatible development versions of 
a system, which is already so complex that modifying the build system 
has been called "poking a hornets nest with a stick", would anchor me 
quite firmly on latest stable, and I likely wouldn't try to answer 
questions on -user, either.  I'm quite happy building the binaries and 
doc from git, but if the development efforts get even more fragmented, 
with devs each competing to get users testing their latest brainstorm, I 
doubt it would end well.  Yes, of course there are power users who can 
handle alpha- and beta-level code, but in the context of trying to make 
lilypond *more* accessible to people who simply want to engrave 
beautiful music with minimal effort, we would be best served by making 
the existing development process more effective and efficient, so that 
only code which is truly beta-plus or RC level would be available to users.


For clarity: I'm not saying devs shouldn't fork LP when they want to 
work out some cool new feature. Git branches are a fine tool for the 
purpose. It's just that there are already so many versions of LP in the 
wild that our support and distribution resources are strained, and 
introducing another 5 versions of LP, with guaranteed problems, may well 
divert developer effort from the main branch or worse, turn the devs and 
power users off answering questions and feature requests entirely.


I'm all for exploring options, but I truly believe this adds a level of 
complexity we can't handle with existing resources and tools, for 
relatively small gains or potential loss of live testing of beta-level code.


Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Curt

I wonder if this is coming across more confusing than it has to be.  You're 
talking about branching a "feature branch" from the mainline (probably the 
development branch: 2.17.24, 2.17.25, etc)  and merging from it (as the 
mainline changes), while the feature branch is improved, until the feature 
branch is stable enough to merge it back into the mainline.

If the feature branch isn't yet stable enough to make a big release like 2.18, 
then no problem, keep it separate and continue to merge from the mainline until 
it's ready, and then merge it back to the mainline.

If new changes are made to the mainline that are inherently incompatible with 
the feature branch, then switch approaches by considering the feature branch as 
a temporary fork.  Instead of merging from the mainline, instead merge from the 
various smaller feature branches that are also merged into the mainline, that 
aren't incompatible with the feature branch.  In other words, if someone wants 
to make a change to the mainline, they do it in their own branch - and then 
when it comes time to contribute it back to the mainline, the fork branch 
accepts it as well.  If there isn't a way to set up this process easily, you 
could probably do this alternatively by doing selective merges from the 
mainline into the feature branch.

>From the perspective of the mainline, it doesn't care because it's not being 
>negatively affected, and it doesn't limit its release schedule.  It doesn't 
>care what is being pulled from it, it only cares what is being pushed to it.  
>From the perspective of the fork branch, it has the time to get stable before 
>it gets re-integrated back into the mainline.

>From the perspective of the user, it isn't as complicated as them having A B 
>and C all seeming equally valid and confusing.  There's the release (2.18, 
>2.19, etc), the development line, and if they want one of these experimental 
>branches they have to use one of the forked releases - I would expect that 
>these types of users would be pretty savvy about keeping track of the 
>differences, and perhaps able to build binaries themselves.

Curt

On Dec 10, 2013, at 5:23 AM, Mike Solomon  wrote:

> Hey all,
> 
> I recently e-mailed the development list about multiple concurrent 
> development versions and I’d like to ask users, especially those currently 
> using the development version, to take the time to respond to a question 
> regarding the proposal.
> 
> If lilypond.org were to propose multiple development versions (say 5 instead 
> of 1), each offering a different set of experimental features (including the 
> canonical development version), and if lilypond.org offered information on 
> which versions were in need of testing by what types of users, would you be 
> interested in helping out by doing some typesetting with these alternative 
> versions?
> 
> Cheers,
> MS
> ___
> 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

Re: How to count the number of notes in a .ly file?

2013-12-10 Thread Keith OHara

Jan Rosseel  rosseel.com> writes:

> 
> Subject line says it about all. How can I count the number of notes present 
in a .ly file? 

You could make a log-file as described at

and count the occurrences of 'note' in the log-file.

Text editors can usually count words; you might do a global
search-and-replace of note -> counted and most editors tell you
how many replacements they performed.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Shane Brandes

Working on many parallel versions seems in some ways seductive, the
dream of improving many things all at once, but I agree keeping to a
single release cycle is definitely less prone to creating all sorts of
unintended problems from conflicting development to documentation
degradation. This program is at point where many many things work
right and very well. The LilyPond wishlist of functionality might be
incomplete, but it will get there or at least it should. We have some
highly useful people keeping things in order, especially David K. In
any event if a roadmap of future effort was released it might allow
people the ability to give there input in a more structured way.
Sometimes it feels like certain things are accomplished as people
happen to get them. or as people are pushed to get to them. Any my
point is the progress seems nebulous at times, maybe it isn't.
in terms of usage I have been running usually the latest release and
jump to the next current when I do more LilyPond work which makes my
updating of the program sporadic and not in line with the release
dates. This is one of the few programs that does not cause any fears
about upgrading to the edge. So I would suspect there are many other
users that upgrade to a unstable release for that bright shiny new
feature or curiosity, but it might not be the case there would be
enough to have any sort of rigorous base of use to support multiple
development versions.
As for plugins, that notion is a dismal sop. As people have pointed
out plugins are hard to maintain long term, and to me at least when i
need such things it really spoke loudly about the basic inadequacy of
the program being used. At least in my experience it has been very
rare that something could not be achieved without resort to simply
waiting it out for the development to catch up to demand, basically
because our user base has an incredible knack for making work arounds
with the existing functionality. And with each release it seems the
need for these work arounds goes down.
So the level of thrashing things out is good to see, keep at it, but
let us not get into a situation where we are forking ourselves to
death and ruining the steak.

Shane

On Tue, Dec 10, 2013 at 12:49 PM, Urs Liska  wrote:
> Am 10.12.2013 18:30, schrieb SoundsFromSound:
>
>> For whatever it's worth, I've always used unstable builds from about 2
>> weeks
>> after I started using LilyPond. I began with stable, but then quickly
>> hopped
>> on the unstables and have had zero issues with my scores.
>>
>> I love the bleeding edge, what can I say?:)  I am a risk-taker! lol
>>
> Using unstable versions of a program like LilyPond is much less a risk than
> using a GUI tool that can crash and wipe away your current work.
>
>
> ___
> 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

Re: point-and-click

2013-12-10 Thread Keith OHara

Tom van der Hoeven  vanderHoeven.biz> writes:

> If you enable  point-and-click you get at each note for instance
> textedit://C:/Users/Tom/Music/altviool/PROKOF%7e1/Altviool/fret.lyp:92:7:7
> can the user change it to for instance
> fret.lyp:92:7:7
> or is there only on or off.

In a LilyPond input file you can only choose on or off.

You can change the string on your system, if you want, by changing
the line that contains 'textedit' in your copy of the file
... /usr/share/lilypond/current/scm/output-ps.scm

I change this in my copy to use a mailto: prefix and tell the operating
system handle a mailto: by sending a message to the editor, rather than
an email.  (The PDF viewer I use ignores link-types that it does not
recognize.)

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Paul Morris

Mike Solomon wrote
> If lilypond.org were to propose multiple development versions (say 5
> instead of 1), each offering a different set of experimental features
> (including the canonical development version), and if lilypond.org offered
> information on which versions were in need of testing by what types of
> users, would you be interested in helping out by doing some typesetting
> with these alternative versions?

I would likely be willing to help test such alternative versions, should
that be the way things are organized.  

I think that if we were talking about just one such alternative version (or
at most two?) instead of five, then this would be a lot simpler and more
feasible from a user's standpoint.  But maybe that would not be enough to
achieve what you're trying to accomplish.

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/survey-on-multiple-development-versions-tp155496p155529.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to count the number of notes in a .ly file?


Am 10.12.2013 19:12, schrieb Jan Rosseel:

Subject line says it about all. How can I count the number of notes
present in a .ly file? Or the number of notes in a music expression?

  


I assume somebody made some (python) script to do this, but I can't
bring it to the surface with my googling skills...

  


Regards,

  


--

JanR


I'm not sure if it will help you, but you can have a look at the 
statistics branch of my Frescobaldi fork at github.com/uliska/frescobaldi.


It's very outdated and only a drafty proof-of-concept, but maybe it 
gives you an idea.


Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

How to count the number of notes in a .ly file?

2013-12-10 Thread Jan Rosseel

Subject line says it about all. How can I count the number of notes
present in a .ly file? Or the number of notes in a music expression? 

 

I assume somebody made some (python) script to do this, but I can't
bring it to the surface with my googling skills... 

 

Regards, 

 

--

JanR

 

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions


Am 10.12.2013 18:30, schrieb SoundsFromSound:

For whatever it's worth, I've always used unstable builds from about 2 weeks
after I started using LilyPond. I began with stable, but then quickly hopped
on the unstables and have had zero issues with my scores.

I love the bleeding edge, what can I say?:)  I am a risk-taker! lol

Using unstable versions of a program like LilyPond is much less a risk 
than using a GUI tool that can crash and wipe away your current work.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread SoundsFromSound

Simon Bailey-5 wrote
> On Tue, Dec 10, 2013 at 5:10 PM, Mike Solomon <

> mike@

> > wrote:
> 
>>
>> I don’t think asking users a question is blasting ahead with a solution.
>>  It is a question that will help me better understand how users use
>> unstable versions LilyPond, which in turn will help me understand the
>> problem.
>>
> 
> i've been using lilypond since 1.4. and my workflow pertaining to
> stable/unstable releases has always been as follows:
> 
> 0. use the latest stable release more or less as soon as it comes out
> 1. keep an eye on the CHANGES file for nice new features
> 2. if a feature is implemented that i feel is an improvement to the stable
> release (this happens quite often), then i upgrade to the unstable release
> 3. i stay on top of  the unstable releases, also still keeping an eye on
> the CHANGES file
> 4. if i run into bugs (not very often anymore), i try to verify and report
> them
> 5. when the unstable branch moves to stable, so do i, and back to step 1.

For whatever it's worth, I've always used unstable builds from about 2 weeks
after I started using LilyPond. I began with stable, but then quickly hopped
on the unstables and have had zero issues with my scores. 

I love the bleeding edge, what can I say? :) I am a risk-taker! lol




-
composer | sound designer 
LilyPond Tutorials (for beginners) --> http://bit.ly/bcl-lilypond
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/survey-on-multiple-development-versions-tp155496p155522.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

On Tue, Dec 10, 2013 at 12:15 PM, Simon Bailey  wrote:

> for instance:
> - the cool new features in 2.17 were \tuplet, tighter spacing,
> dot.notation.of.objects and \markLengthOn, several articulations feature;
> - 2.15 didn't have much exciting for me in it -- here i stuck with 2.14
> until 2.16 came out.
> - 2.13 was a good development version with the instrument names fixed, q
> for repeating chords, dotted/dashed slurs, two-sided margins, white-out,
> segno bar-line, cresc text spanners, the partcombiner, cueDuringWithClef,
> beam collisions, ... [2.14. was a GOOD release]
>
> My personal upgrading experience is similar. I had a hiatus of a couple of
years (at least) when I didn't use LilyPond (dating back to around 2.13.17
or so, IIRC), but recently, I was using 2.16.2 on my main computer until it
became necessary to tweak things to fit a stylesheet I was working on, then
I installed LilyDev on my iMac and eventually fired up my old Debian box. I
used 2.17.26 or so for awhile, until I found out that the most recent
releases incorporate MIDI panning, so right now I do my work on a hacked
version of 2.17.95 for Mac (copying in modified versions of the part
combiner Scheme file and the Feta font). Even though it doesn't take much
to integrate those hacks now, I'm reluctant to do much upgrading unless
there's a benefit to doing so.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Simon Bailey

On Tue, Dec 10, 2013 at 5:10 PM, Mike Solomon  wrote:

>
> I don’t think asking users a question is blasting ahead with a solution.
>  It is a question that will help me better understand how users use
> unstable versions LilyPond, which in turn will help me understand the
> problem.
>

i've been using lilypond since 1.4. and my workflow pertaining to
stable/unstable releases has always been as follows:

0. use the latest stable release more or less as soon as it comes out
1. keep an eye on the CHANGES file for nice new features
2. if a feature is implemented that i feel is an improvement to the stable
release (this happens quite often), then i upgrade to the unstable release
3. i stay on top of  the unstable releases, also still keeping an eye on
the CHANGES file
4. if i run into bugs (not very often anymore), i try to verify and report
them
5. when the unstable branch moves to stable, so do i, and back to step 1.

for instance:
- the cool new features in 2.17 were \tuplet, tighter spacing,
dot.notation.of.objects and \markLengthOn, several articulations feature;
- 2.15 didn't have much exciting for me in it -- here i stuck with 2.14
until 2.16 came out.
- 2.13 was a good development version with the instrument names fixed, q
for repeating chords, dotted/dashed slurs, two-sided margins, white-out,
segno bar-line, cresc text spanners, the partcombiner, cueDuringWithClef,
beam collisions, ... [2.14. was a GOOD release]

[etc. etc. for older development versions. i can't find the change files
online for the older ones, but i remember there were lots of interesting
new features in 2.9 and 2.7].

having multiple development versions with different feature sets in them
would be, in my eyes, a large waste of disk-space on the lilypond server.
also, as others have mentioned, it would be maintenance hell for helpful
mailing list inhabitants. not to mention that you're less likely to catch
weird interactions between new features, which do occur every now and then
in the development versions...

i think one reason for less forward movement is that a lot of really
groundbreaking, spectacular stuff has been covered. a lot of the new
features in this release are improvements on sufficiently functioning new
features, making them better. and we all know that 80% of the time on a
project is invested in the final 20% of the work.

yes, contributing to the project is difficult and convoluted; not helped by
some very unique people working on the project, but i wouldn't want to miss
any of them working on my favourite piece of software. graham and david,
just to name two very prominent ones, have had an amazing influence on
lilypond and it wouldn't be where it is now without them.

just my two euro-cents,
sb

-- 
Do not meddle in the affairs of trombonists, for they are subtle and quick
to anger.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

point-and-click

2013-12-10 Thread Tom van der Hoeven


If you enable  point-and-click you get at each note fo instance

textedit://C:/Users/Tom/Music/altviool/PROKOF%7e1/Altviool/fret.lyp:92:7:7

can the user change it to for instance

fret.lyp:92:7:7

or is there only on or off.

Tom



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

On Dec 10, 2013, at 6:32 PM, David Kastrup  wrote:

> Carl Peterson  writes:
> 
>> On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup  wrote:
>> 
>>> If we have branches with personal interests, it must become more
>>> feasible for the respective authors with personal interests to
>>> provide binaries if they consider that a good idea.  Any solution
>>> that will only work via the "Phil, do more" route is not going to
>>> scale.
>> 
>> This, to me, sounds like a "plug-in" solution is needed, at least for
>> things that do not involve changing the C++ code (and maybe even
>> then).
> 
> That's very much my opinion.  Recompilation is a very high threshold,
> and crossing it basically is platform-dependent.
> 
> That means that we should strive to factor out as much as possible into
> Scheme.  That is not, by itself, going to help.  It is also necessary to
> factor the stuff into sensible units.
> 
> If we take an example of one item that has been mentioned: footnotes.
> Footnotes consist of material that is anchored to locations on the page,
> and that is assembled into a footnote block of its own taking space on
> the page.
> 
> Basically all of that is done interweaved into other C++ code.  Which
> does not make a whole lot of sense since it is a reasonably independent
> task.
> 
> If we are taking a look at why this happens, we can basically state as a
> goal to factor out the "page builder".  The page builder is part of the
> page breaking calculation, and as such
> 
> a) its material have to be placed in special lists which are processed
> for page breaking
> b) its material contains items like "springs" that are not actually
> creatable or accessible in Scheme.
> 
> So if we are going to use markup lists for building up a page from its
> elements, we need to have proper Scheme and likely also LilyPond
> representations of the items making up the material assembled into a
> page.
> 
> Refactoring the page building into a stage where its basic operations
> can be done from Scheme/LilyPond would be a first big step towards being
> able to experiment with different schemes without recompilation.
> 
> The next big step would be to create a modular structure where it is not
> necessary to replace the page builder for a feature like footnotes, but
> where you can plug in elements like footnotes by writing code for them
> and plugging this code into a single, extensible page builder with
> appropriate interfaces.
> 
> Then we can have, without recompilation, tools that provide smarter
> footnotes, different layouts of them, margin notes and other stuff
> without interfering with other tools available for the page composition.

I agree that this is a great candidate for refactoring.  I think one way to 
frame the problem would be to imagine that someone wanted to take on this task, 
which is pretty ambitious and would likely require a lot of subtasks in 
extracting out the page breaker.  Each of these subtests would require 
independent verification, and it is likely that the entire project could be 
done separately from the main branch.  It would probably require extensive user 
testing to make sure that all the kinks were ironed out.

Let’s say that I set up a version of LilyPond called modular-footnote-LilyPond 
in which I develop this modularity.  How, if at all, can users test this before 
it makes it into the development version?

Cheers,
MS
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

Pavel Roskin  writes:

> On Tue, 10 Dec 2013 11:00:02 -0500
> Carl Peterson  wrote:
>
>> This, to me, sounds like a "plug-in" solution is needed, at least for
>> things that do not involve changing the C++ code (and maybe even
>> then).
>
> I would hate the situation when I download a source for a piece of music
> and find that it requires a obscure plugin that was written for an old
> version of Lilypond ten years ago and never updated since then.
>
> The lifespan of music is much longer than the lifespan of Lilypond
> versions.  We should try to keep Lilypond scores maintainable for years
> and maybe decades from now.  Plugins can create problems.
>
> I'm not against plugins, it's just something to think about.

In the LaTeX universe, packages survive rather long before becoming
unusable.  Binary plugins tend to last less long.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

Carl Peterson  writes:

> On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup  wrote:
>
>> If we have branches with personal interests, it must become more
>> feasible for the respective authors with personal interests to
>> provide binaries if they consider that a good idea.  Any solution
>> that will only work via the "Phil, do more" route is not going to
>> scale.
>
> This, to me, sounds like a "plug-in" solution is needed, at least for
> things that do not involve changing the C++ code (and maybe even
> then).

That's very much my opinion.  Recompilation is a very high threshold,
and crossing it basically is platform-dependent.

That means that we should strive to factor out as much as possible into
Scheme.  That is not, by itself, going to help.  It is also necessary to
factor the stuff into sensible units.

If we take an example of one item that has been mentioned: footnotes.
Footnotes consist of material that is anchored to locations on the page,
and that is assembled into a footnote block of its own taking space on
the page.

Basically all of that is done interweaved into other C++ code.  Which
does not make a whole lot of sense since it is a reasonably independent
task.

If we are taking a look at why this happens, we can basically state as a
goal to factor out the "page builder".  The page builder is part of the
page breaking calculation, and as such

a) its material have to be placed in special lists which are processed
for page breaking
b) its material contains items like "springs" that are not actually
creatable or accessible in Scheme.

So if we are going to use markup lists for building up a page from its
elements, we need to have proper Scheme and likely also LilyPond
representations of the items making up the material assembled into a
page.

Refactoring the page building into a stage where its basic operations
can be done from Scheme/LilyPond would be a first big step towards being
able to experiment with different schemes without recompilation.

The next big step would be to create a modular structure where it is not
necessary to replace the page builder for a feature like footnotes, but
where you can plug in elements like footnotes by writing code for them
and plugging this code into a single, extensible page builder with
appropriate interfaces.

Then we can have, without recompilation, tools that provide smarter
footnotes, different layouts of them, margin notes and other stuff
without interfering with other tools available for the page composition.

The LaTeX core project is rather religiously keeping from ever touching
the canonical TeX binary, and this has had quite a few ridiculous
consequences.  But it also enabled a large body of grown LaTeX/TeX code
that can be used in parallel, due to some abstractions and interfaces
and conventions that are far from convincing or enforceable in their
technical implementation but which definitely do much more for being
able to let multiple independent solutions be combined than the basic
"plain TeX" format does.

> The question is, if we're looking at releasing these binaries to
> reflect personal interest, how much are they actually going to be
> used? I have the feeling, though it may be unjustified, that while
> there may be a few people who would grab a binary with an experimental
> feature (self included, if it is one that I'm interested in and know
> something about), the use of the binaries may not be enough to justify
> the extra effort to make them available.

I share that concern.  For that reason, I'd consider it important to
spend a significant amount of effort not on thinking about "how can
expert programmers make LilyPond do something new" rather than "how can
experienced users make LilyPond do something new".  Or even something
old.  One part of the "programmer"/"user" distinction is that adding new
functionality should _not_ require tampering with the existing
installation, making it compile existing files differently when they
don't access the added functionality.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions


Am 10.12.2013 17:10, schrieb Mike Solomon:


On Dec 10, 2013, at 6:02 PM, David Kastrup > wrote:



"Phil Holmes" mailto:m...@philholmes.net>> writes:


- Original Message -
From: "David Kastrup" mailto:d...@gnu.org>>


If we have branches with personal interests, it must become more
feasible for the respective authors with personal interests to provide
binaries if they consider that a good idea.  Any solution that will 
only

work via the "Phil, do more" route is not going to scale.

--
David Kastrup



I think it would potentially be feasible to have a page with a variety
of builds of single binary types.  This could potentially be managed a
la patchy, but the question is: if we had a set of, say Linux x86
builds to try out, would people bother?

It might make more sense to think about improved ways of creating
stable releases during a continuing development cycle.


Well, that was supposed to be related to that.  Now Mike has chosen to
blast ahead with a solution of his before I or someone else made a
formal exposition of the basic problem.


I don't think asking users a question is blasting ahead with a 
solution.  It is a question that will help me better understand how 
users use unstable versions LilyPond, which in turn will help me 
understand the problem.


Making formal expositions of basic problems is one way to identify a 
problem, but it is not the only way.  In a lot of my work, I find that 
entertaining solutions without a clear understanding of a problem is 
the best way to understand what a problem is.


With respect to the subject of the e-mail, I'm looking forward to more 
responses like that of Carl Peterson (thank you Carl).


Cheers,
MS



From the perspective of a user:
I can _imagine_ that I would try out different binaries with specific 
features. But I can also imagine that this would cause confusion on the 
user side.
I think to make something like this understandable for users one should 
have a barrier at least like asking "would you like to beta test? Come 
in and get experimental features, but understand it's not intended for 
production use"


Although i understand the idea I'm also not sure if that'l be workable.
I think the incentive to try out such a custom binary would be much 
higher if I were somehow involved in the issue. Say, a discussion on 
lilypond-user about the feature, and then the developer says: Hey, I can 
do this, go to ..., grab a build and test.


As a concrete example: When working on our Fried edition we came to the 
point where Janek created some patches that were necessary to improve 
some issues. So I couldn't reproduce the scores anymore. When I asked 
him if he could give me the custom builds he told me they were around 
250 MB in size, and producing something along the lines of a binary 
release was a much more involved process.
Eventually I managed to set up my system to build LilyPond myself so our 
problem was solved - but that's definitely beyond the range of regular 
users that should be addressed with Mike's suggestion.


To come back to your suggestion: If I were asked to test a specific 
build for some new features I'd surely do that. But when just lurking 
around on lilypond.org and thinking about downloading something I'm not 
so sure about that. And I think I'm already more involved as a user than 
a good part of our 'audience'.

So finally I doubt this would be worth the effort.

I don't have any ideas about how to improve the development cycle, so I 
can't comment on Phil's and David's discussion.


But of course Carl's suggestion appeals to me because it would lower the 
barrier to contribute to LilyPond because added material would much less 
affect the stability of the overall product.

Of course it's not necessarily a plugin system, it could also be a library.
OTOH (equally of course) this would only help for smaller additions that 
can be completely realized with .scm or .ly files, not the "ambitious 
additions" you probably had in mind that could be complicated to integrate.


Urs


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Pavel Roskin

On Tue, 10 Dec 2013 11:00:02 -0500
Carl Peterson  wrote:

> This, to me, sounds like a "plug-in" solution is needed, at least for
> things that do not involve changing the C++ code (and maybe even
> then).

I would hate the situation when I download a source for a piece of music
and find that it requires a obscure plugin that was written for an old
version of Lilypond ten years ago and never updated since then.

The lifespan of music is much longer than the lifespan of Lilypond
versions.  We should try to keep Lilypond scores maintainable for years
and maybe decades from now.  Plugins can create problems.

I'm not against plugins, it's just something to think about.

-- 
Regards,
Pavel Roskin

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

On Dec 10, 2013, at 6:02 PM, David Kastrup  wrote:

> "Phil Holmes"  writes:
> 
>> - Original Message - 
>> From: "David Kastrup" 
>>> 
>>> If we have branches with personal interests, it must become more
>>> feasible for the respective authors with personal interests to provide
>>> binaries if they consider that a good idea.  Any solution that will only
>>> work via the "Phil, do more" route is not going to scale.
>>> 
>>> -- 
>>> David Kastrup
>> 
>> 
>> I think it would potentially be feasible to have a page with a variety
>> of builds of single binary types.  This could potentially be managed a
>> la patchy, but the question is: if we had a set of, say Linux x86
>> builds to try out, would people bother?
>> 
>> It might make more sense to think about improved ways of creating
>> stable releases during a continuing development cycle.
> 
> Well, that was supposed to be related to that.  Now Mike has chosen to
> blast ahead with a solution of his before I or someone else made a
> formal exposition of the basic problem.

I don’t think asking users a question is blasting ahead with a solution.  It is 
a question that will help me better understand how users use unstable versions 
LilyPond, which in turn will help me understand the problem.

Making formal expositions of basic problems is one way to identify a problem, 
but it is not the only way.  In a lot of my work, I find that entertaining 
solutions without a clear understanding of a problem is the best way to 
understand what a problem is.

With respect to the subject of the e-mail, I’m looking forward to more 
responses like that of Carl Peterson (thank you Carl).

Cheers,
MS___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup  wrote:

>
>
> If we have branches with personal interests, it must become more
> feasible for the respective authors with personal interests to provide
> binaries if they consider that a good idea.  Any solution that will only
> work via the "Phil, do more" route is not going to scale.
>

This, to me, sounds like a "plug-in" solution is needed, at least for
things that do not involve changing the C++ code (and maybe even then).

The question is, if we're looking at releasing these binaries to reflect
personal interest, how much are they actually going to be used? I have the
feeling, though it may be unjustified, that while there may be a few people
who would grab a binary with an experimental feature (self included, if it
is one that I'm interested in and know something about), the use of the
binaries may not be enough to justify the extra effort to make them
available.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

"Phil Holmes"  writes:

> - Original Message - 
> From: "David Kastrup" 
>>
>> If we have branches with personal interests, it must become more
>> feasible for the respective authors with personal interests to provide
>> binaries if they consider that a good idea.  Any solution that will only
>> work via the "Phil, do more" route is not going to scale.
>>
>> -- 
>> David Kastrup
>
>
> I think it would potentially be feasible to have a page with a variety
> of builds of single binary types.  This could potentially be managed a
> la patchy, but the question is: if we had a set of, say Linux x86
> builds to try out, would people bother?
>
> It might make more sense to think about improved ways of creating
> stable releases during a continuing development cycle.

Well, that was supposed to be related to that.  Now Mike has chosen to
blast ahead with a solution of his before I or someone else made a
formal exposition of the basic problem.  We will need to come to turns
with how we will be trying to maintain a reasonable rate of stable
releases without stifling forward-looking development more than is
needed to not let the development diverge from the goal of stability
terminally.

This will certainly be a topic early in the 2.19 cycle which strictly
speaking is already on.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

On Dec 10, 2013, at 5:07 PM, Phil Holmes  wrote:

> 
> - Original Message - From: "Mike Solomon" 
> To: "LilyPond Users" 
> Sent: Tuesday, December 10, 2013 1:23 PM
> Subject: survey on multiple development versions
> 
> 
> Hey all,
> 
> I recently e-mailed the development list about multiple concurrent 
> development versions and I’d like to ask users, especially those currently 
> using the development version, to take the time to respond to a question 
> regarding the proposal.
> 
> If lilypond.org were to propose multiple development versions (say 5 instead 
> of 1), each offering a different set of experimental features (including the 
> canonical development version), and if lilypond.org offered information on 
> which versions were in need of testing by what types of users, would you be 
> interested in helping out by doing some typesetting with these alternative 
> versions?
> 
> Cheers,
> MS
> ___
> 
> It seems to be fixing a problem we don't have.  What would be the benefit?

Currently, LilyPond development is down from the level it was 2-3 years ago in 
terms of people proposing ambitious improvements (medieval music, footnotes, 
page breaking algorithms, etc.) with the exception of David’s work.  I think 
that at least part of the reason for this is because of difficulties 
integrating large projects into the main branch.

> It might make more sense to think about improved ways of creating stable 
> releases during a continuing development cycle.

What you say above is a more general way to state the program.  Generally, we 
need to figure out how can we have a robust continuous development cycle 
benefiting from multiple players while continuing to create stable releases.  
The survey I’m sending out is trying to gage one way that user participation 
may help in this - it is certainly not the only way.

Cheers,
MS
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Phil Holmes

- Original Message - 
From: "David Kastrup" 


If we have branches with personal interests, it must become more
feasible for the respective authors with personal interests to provide
binaries if they consider that a good idea.  Any solution that will only
work via the "Phil, do more" route is not going to scale.

--
David Kastrup



I think it would potentially be feasible to have a page with a variety of 
builds of single binary types.  This could potentially be managed a la 
patchy, but the question is: if we had a set of, say Linux x86 builds to try 
out, would people bother?


It might make more sense to think about improved ways of creating stable 
releases during a continuing development cycle.


--
Phil Holmes 



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

"Phil Holmes"  writes:

> It seems to be fixing a problem we don't have.  What would be the
> benefit?

We have a problem reconciling potentially destabilizing work with the
necessity to put out releases, in particular stable releases.  That
definitely _is_ a problem we have.

I don't see Mike's particular proposal as currently tenable, either.

> I would also mention that, for this to work, there would need to be
> parallel documentation streams, too - otherwise users would read the
> docs for A, assume it's in B and rightly complain if it wasn't.  This
> would entail 1) even _more_ confusion about which is the right doc set
> to read and 2) an impossible upload.  Currently my internet access is
> screwed for about 5 hours every fortnight while I upload the new
> version.  I don't see I could lose it for 5 times that long.  It would
> also exceed my monthly quota in a single day.

Well, this is one point we should likely be addressing at some point of
time: we can probably cut down on platforms.  Of course, that alone will
not buy us enough leeway for a "5 times as much" scheme.

If we have branches with personal interests, it must become more
feasible for the respective authors with personal interests to provide
binaries if they consider that a good idea.  Any solution that will only
work via the "Phil, do more" route is not going to scale.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

2013-12-10 Thread Phil Holmes

- Original Message - 
From: "Mike Solomon" 

To: "LilyPond Users" 
Sent: Tuesday, December 10, 2013 1:23 PM
Subject: survey on multiple development versions

Hey all,

I recently e-mailed the development list about multiple concurrent 
development versions and I’d like to ask users, especially those currently 
using the development version, to take the time to respond to a question 
regarding the proposal.

If lilypond.org were to propose multiple development versions (say 5 instead 
of 1), each offering a different set of experimental features (including the 
canonical development version), and if lilypond.org offered information on 
which versions were in need of testing by what types of users, would you be 
interested in helping out by doing some typesetting with these alternative 
versions?

Cheers,
MS
___

It seems to be fixing a problem we don't have.  What would be the benefit?

I would also mention that, for this to work, there would need to be parallel 
documentation streams, too - otherwise users would read the docs for A, 
assume it's in B and rightly complain if it wasn't.  This would entail 1) 
even _more_ confusion about which is the right doc set to read and 2) an 
impossible upload.  Currently my internet access is screwed for about 5 
hours every fortnight while I upload the new version.  I don't see I could 
lose it for 5 times that long.  It would also exceed my monthly quota in a 
single day.

--
Phil Holmes 

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: adding engravers

Noeck  writes:

> Sorry David,
>
> I thought I was clear enough, but obivously not. I didn't want you to
> take that time and write all that. I know what you wrote. I just wanted
> to show, that new and unexperienced users have a different perception of
> "exception". Thank you anyway.
>
>> Can you give an example?  text} should nowadays never be bad unless we
>> are inside of Scheme.
>
> I didn't know that. I remembered it from lyrics ending with text}, but
> is indeed not the case any more.

There were several issues related to both markups and lyrics.  Pertinent
last change would seem to be 2.17.4:

commit 38a4081efa4a8ee2f5da780ca0ed2991627afc46
Author: David Kastrup 
Date:   Sun Sep 30 02:21:00 2012 +0200

Issue 2869: Regularize lyrics lexer mode

That makes lyrics mode rather similar to markup mode regarding how
words are formed.  {} are never considered part of words unless
enclosed in quotes.  Unquoted words do not contain whitespace, braces,
quotes, backslashes, numbers or Scheme expressions.  In addition, they
cannot start with * . = and | since that would mess with duration,
assignment and barcheck syntax.  This removes some remaining
TeX-oriented cruft in the lexer.  The set of word-non-starters might
need revisiting, but at least the regtests seem to pass.

Actually, I would have thought to have cleaned that up before 2.16 but
it appears like at least in this respect the years are passing slower
than they feel to me.

> Thanks for your work, that has indeed improved a lot of those small
> issues!

It's probably worth pointing out that the above Issue 2869 was _not_ a
longstanding issue in the tracker.  Its first appearance was immediately
accompanied with a patch.  So why would I have changed matters appearing
to new and inexperienced users' perception as "exception" when my own
perception would be a completely different one?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: adding engravers

2013-12-10 Thread Noeck

Sorry David,

I thought I was clear enough, but obivously not. I didn't want you to
take that time and write all that. I know what you wrote. I just wanted
to show, that new and unexperienced users have a different perception of
"exception". Thank you anyway.

> Can you give an example?  text} should nowadays never be bad unless we
> are inside of Scheme.

I didn't know that. I remembered it from lyrics ending with text}, but
is indeed not the case any more.

Thanks for your work, that has indeed improved a lot of those small issues!

Cheers,
Joram


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

On Dec 10, 2013, at 3:41 PM, Carl Peterson  wrote:

> On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon  wrote:
> Hey all,
> 
> I recently e-mailed the development list about multiple concurrent 
> development versions and I’d like to ask users, especially those currently 
> using the development version, to take the time to respond to a question 
> regarding the proposal.
> 
> If lilypond.org were to propose multiple development versions (say 5 instead 
> of 1), each offering a different set of experimental features (including the 
> canonical development version), and if lilypond.org offered information on 
> which versions were in need of testing by what types of users, would you be 
> interested in helping out by doing some typesetting with these alternative 
> versions?
> 
> The problem I see is an issue of mixing and matching. What if there is a 
> feature I want to use on Development Version A and one I want to use on 
> Development Version B, within the same score?

The idea is that the canonical version will pick up all inclusion-worthy 
features a few weeks / months after the experimental versions.  It is true that 
it’s annoying to wait, but the current state of things is for these features 
either to not exist at all or exist at a much later date.  I think that the 
scenario you describe above, while frustrating, is preferential to the current 
state of things.

> I also foresee a multiplication of the issues regarding who is using what 
> version on this list, as in:
> 
> Today:
> 
> A: "I have this problem. I am using version 2.17.3"
> B: "We fixed this problem in 2.17.23"
> 
> With multiple versions:
> 
> A: "I have this problem. I am using version 2.19.A.3"
> B: "This was fixed on version 2.19.B"
> A: "Okay, that fixed that, now I have this problem."
> C: "This was fixed on version 2.19.C"
> A: "I'm confused. How do I fix both of these problems?”

The versions are always “branched" off of canonical development, like so:

canonical development
|— A
|— B
|— C

Think of canonical development as a foundation for A, B and C. This means that 
any bugs fixed in the canonical version will be fixed in the experimental one 
unless the experiments are so experimental that they break everything, which 
we’d obviously try to avoid.  Conversely, a problem in branch A will never be 
fixed in just branch B - it will first be fixed in A and then applied to all of 
the branches (or it will persist in all the branches if no one catches it).

Let’s assume that canonical devel is at 2.19.23.  You are using 2.19.3.A.  It 
would go as follows:

A: "I have this problem. I am using version 2.19.3.A”

an appropriate response would be either:

“This was fixed with version 2.19.23.”
or “This was fixed with version 2.19.23.A”
but never “This was fixed with version 2.19.23.B"

It is true, though, that attentiveness to versioning would become important for 
testers and responders alike.

Cheers,
MS___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: survey on multiple development versions

On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon  wrote:

> Hey all,
>
> I recently e-mailed the development list about multiple concurrent
> development versions and I’d like to ask users, especially those currently
> using the development version, to take the time to respond to a question
> regarding the proposal.
>
> If lilypond.org were to propose multiple development versions (say 5
> instead of 1), each offering a different set of experimental features
> (including the canonical development version), and if lilypond.orgoffered 
> information on which versions were in need of testing by what types
> of users, would you be interested in helping out by doing some typesetting
> with these alternative versions?
>

The problem I see is an issue of mixing and matching. What if there is a
feature I want to use on Development Version A and one I want to use on
Development Version B, within the same score? I also foresee a
multiplication of the issues regarding who is using what version on this
list, as in:

Today:

A: "I have this problem. I am using version 2.17.3"
B: "We fixed this problem in 2.17.23"

With multiple versions:

A: "I have this problem. I am using version 2.19.A.3"
B: "This was fixed on version 2.19.B"
A: "Okay, that fixed that, now I have this problem."
C: "This was fixed on version 2.19.C"
A: "I'm confused. How do I fix both of these problems?"
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

survey on multiple development versions

Hey all,

I recently e-mailed the development list about multiple concurrent development 
versions and I’d like to ask users, especially those currently using the 
development version, to take the time to respond to a question regarding the 
proposal.

If lilypond.org were to propose multiple development versions (say 5 instead of 
1), each offering a different set of experimental features (including the 
canonical development version), and if lilypond.org offered information on 
which versions were in need of testing by what types of users, would you be 
interested in helping out by doing some typesetting with these alternative 
versions?

Cheers,
MS
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: adding engravers

Noeck  writes:

> - what does " mean? sometimes enclosing in "" is needed sometimes not

It's a string.  Words do not need to get enclosed in quotes when they
a) are not a notename
b) consist of alphabetic characters or non-ASCII characters, possibly with
_single_ - or _ signs in their middle.

> - sometimes # before the value is needed sometimes not

In general, markup function arguments need # for non-markup values.
That's not restricted to strings.  The rest will usually work without #.

> - sometimes it's Staff sometimes \Staff

It's \Staff for _copying_ the definition for Staff, and Staff for
_specifying_ it.  Just like you write

music = ...

for specifying music and \music for copying it.

> - most commands start with \ arguments not, but it is not: \key d major

Any previously defined _expression_ may be referenced with \name as long
as the name's syntax is compatible with that.  If it isn't, you can
still reference it as \"name that is not a word".

> - mostly spaces do not matter, but sometimes text} is bad

Can you give an example?  text} should nowadays never be bad unless we
are inside of Scheme.

> - what is this tagline I didn't call for?
> - \transpose c d \relative {…} is ok, but \relative \transpose c d {…} not

It's ok and accepted but probably doesn't do what you expect it to do.
But then how is LilyPond to know that you mean \transpose c d \relative
{...} when you actually write \relative \transpose c d {...}?

Both are different things.  You are probably annoyed that \relative is
_ignored_ when applied to a transposed expression.  But if you write

\relative \transpose c d { g b a c d e }

do you really want to see

\relative { a cis' b d e fis }, namely \absolute { a cis'' b' d'' e'' fis'' }

or would you have expected to rather see

\relative { a cis b d e fis }, namely \absolute { a cis' b d' e' fis' } ?

How is LilyPond going to guess before evaluating \transpose that you are
going to use the result in a \relative context, and that it is supposed
to _first_ apply the purportively following \relative _before_ doing the
transposition?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypond.org "Pondings"


Am 10.12.2013 10:21, schrieb Mike Solomon:


Thinking out loud, perhaps one solution would be a web-based 
submission mechanism, not unlike OpenLilyLib.




Surely you've already prepared material for shelter? ;-/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Problems with LilyJAZZ.ily

Am 10.12.2013 07:19, schrieb Urs Liska:

Am 10.12.2013 00:49, schrieb Janek Warcho?:

2013/12/8 David Kastrup:

"Shall be" does not state when. It's certainly not a replacement for a
formal submission. If someone finds a way to get hold of the author and
get him to place the thing in some public place with a clear license
statement, it would not get lost in case he becomes harder to reach.

The problem is that he had already become harder to reach.
Anyway, i think it would be a good idea to try to contact him using
other means - telephone, other email?
But this should be done by someone speaking German. For example, i
found
thishttp://telefonbuch-suche.com/torsten-h%C3%A4mmerle-kleinschmidtstra%C3%9Fe-69115-heidelberg
but i'm not sure if it could be of actual use because i don't
understand German and thus don't understand the full context :-/

Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

I'll give that a try.
But it's of course not sure that this actually points at the right
place ...

Trying to call that number was responded by "Unknown Number".
Together with this:
http://lists.gnu.org/archive/html/lilypond-user/2013-12/msg00499.html

I think we can conclude that Torsten Hämmerle _is_ unavailable for the
time being.

Wo what should we do?
I reread the statement in Torsten's initial message:

" At any rate, the whole LilyJAZZ issue shall be open and free (just
like Lilypond), so I first had to create my own fonts in order to become
independent of commercial ones."

and I'm quite positive that this is meant as a submission to LilyPond's
licence.

Please have look at
https://github.com/openlilylib/snippets/blob/master/custom-music-fonts/LilyJAZZ/README.md

for my reasoning and proposed solution.

So: All that have worked with and on LilyJAZZ in the meantime, please
make it available in our library.
Please create an includable LilyJAZZ.ily file in that folder, a working
LilyJAZZ-example.ly file beside, and complete the README with
installation/usage instructions.

Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypond.org "Pondings"