Re: Chords in LilyPond

[Simon Albrecht]

Am 25.05.2017 um 16:46 schrieb msk...@ansuz.sooke.bc.ca:

This thread:
   http://lists.gnu.org/archive/html/lilypond-user/2017-01/msg00248.html
User wants to engrave a chord they describe as "Gm7(b5)/F" and is told to
type
   g : m7.5- / f
Note the desired output does not contain a colon or hyphen.


Well, input syntax does not equal desired output.


   Using that
suggestion, as in
   \new ChordNames { \chordmode { g : m7.5- / f } }
will actually engrave
   Gø/F
(where the ø is superscript).  User doesn't pursue it further, but this
output does not closely resemble the requested
   Gm7(b5)/F


ø is a quite common abbreviation for ‘half-diminished chord’, so this is an 
exemplary use case for chordExceptions and perfectly reasonable that Lily uses 
it by default. It does not ‘closely resemble the requested Gm7(b5)/F’ visually, 
but LilyPond still is a WYSIWYM program, and the two are perfectly equivalent 
in meaning.

Best, Simon


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

Re: Chords in LilyPond

[Thomas Morley]

'

2017-05-25 16:46 GMT+02:00  :
> On Thu, 25 May 2017, Thomas Morley wrote:
>> I vaguely remember such threads.
>> Though, could you give some examples (or links) so it is present here as 
>> well?

Hi Mathew,

thanks for collecting the links, examples and your comments about it.
Let me add some own.

> Request for "rootless slash chords" from 2014 but brought up in a thread
> here last month:
>   https://sourceforge.net/p/testlilyissues/issues/3909/
> The discussion on that issue assumes that the user will enter something
> like
>   \chordmode { c c/e c/g }
> to get the desired output of
>   C /E /G
> with LilyPond doing some kind of translation to not show roots when there's
> a slash, but what would make sense would be for the user to enter
>   \chordtext { c /e /g }
> and get
>   C /E /G
> That would be easy by directly printing the input with only formatting
> translations (I am counting the lowercase to uppercase conversion as
> formatting) and much harder with an attempt to go to notes and back in
> between.

Under the link above you'll find two solutions. Ofcourse both scope
with the current way how LilyPond works.
I'll comment on the proposed 'chordtext '-input-mode below.

>
> Request for "alt" notation for chords:
>   http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00644.html
> Here a chord symbol *does not correspond to a fixed set of notes*; it's
> deliberately leaving a choice for the performer, making any translation to
> notes and back difficult.  The thread includes a suggested "solution" of
>   \chords {
> \once\override ChordName.Text = \markup { G \super { 7 alt } }
> g:7^5
>   }
> but it sure would be easier to just type
>   \chordtext { G7alt }

We do have a way to print Galt
\new ChordNames \chordmode { g:7.9-.10-.11+.13- }
It is defined in 'ignatzekExceptions'
To get G7alt one could add/replace the relevant setting.

g:7.9-.10-.11+.13- looks ofcourse much more complicated than
\chordtext { G7alt }, though current LilyPond tries to work on the
_same_ chordmode-input to create Staff, ChordNames, FretBoards and
Midi.
So we _need_ to know which pitches are actually to engrave.

The proposed chordtext can't do so, not to speak of reusing the input
transposed or however processed.

I'm not sure yet whether a special chordtext-inputmode (added to the
existing ones) will gain us more confusing than doing us a favor.

> Note the desired symbol does NOT contain a colon or a caret or a 5; why
> are those things needed in the input?

The colon is needed to separate duration-input from pitch-input.
In c8:7 the chord lasts an 8th. In chordtext you would need to find a
possibility to set the duration as well.

The caret may be demonstrated by:

input = \chordmode { b,,1:^3 }
<<
  \new ChordNames \with { chordNameExceptions = \powerChordExceptions }
\input
  \new FretBoards \input
  \new Staff { \clef "G_8" \input }
>>

All working.

Again \chordtext { B5 } is far easier, but not suitable for Staff and
FretBoards.

> They exist to help LilyPond decide
> on a note set, which is unnecessary for engraving the symbol.  Requiring
> an entire line of override code just for one symbol is a lot to ask, too;
> and yes, it could be achieved with less per-chord work when there are a
> lot of them by defining a chord name override or a macro, but this is
> still a lot harder than just typing
>   \chordtext { G7alt }
> Any ambiguity in what that *engraves* is only at the level of "which parts
> of this symbol does the user want superscripted?".  We cannot expect to
> translate it to notes cleanly without more information about what it
> means, but we don't need to know what it means to engrave it.
>
> This thread:
>   http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00600.html
> User wants to enter:
>   \chordmode { e13 }
> and get
>   E13
> but instead he gets
>   E9 13
> The reasons for this are arcane,

I strongly disagree with the wording, reread the link, I gave referencies.

> and attempts to "solve" it are predicated
> on deciding which notes are meant to be in an E13 chord when it's not
> otherwise modified - which is not a universally agreed point among
> musicians, and should be completely irrelevant to the question of how to
> engrave the letter "E" and the numerals "1" and "3".

Same as above for Staff, FretBoard and midi.

> At one point in the
> discussion is it pointed out that he could get
>   E13
> by entering
>   \chordmode { e:11.13 }
> but I think it ought to be clear why that isn't ideal.

This was my own suggestion.

>
> This thread:
>   http://lists.gnu.org/archive/html/lilypond-user/2017-01/msg00248.html
> User wants to engrave a chord they describe as "Gm7(b5)/F" and is told to
> type
>   g : m7.5- / f
> Note the desired output does not contain a colon or hyphen.  Using that
> suggestion, as in
>   \new ChordNames { \chordmode { g : m7.5- / f } }
> will actually engrave
>   Gø/F
> (where the ø is superscript).  User doesn't 

Re: Chords in LilyPond

[mskala]

On Thu, 25 May 2017, Mats Behre wrote:
> While this is true, in order to support things like transposition (which I for
> one use frequently) I think you will have to devise formats for input and
> internal representation (they may be the same) that identifies both all

Yes, if you're doing transposition - or stuff like auto-generated guitar
diagrams, which is another thing people like to have - then you need an
internal representation that admits generating note sets.  A
print-what-I-typed feature doesn't address that and couldn't replace the
existing mess; it would have to be an addition, not a replacement.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Unofficial MusicXML test suite access problem

[Menu Jacques]

Hello folks,

— For your information —

The links in that page:


http://lilypond.org/doc/v2.19/input/regression/musicxml/collated-files.html

seem to be broken or to lead to a zip archive containing an empty « home » 
directory.

The same holds for:


http://lilypond.org/doc/v2.18/input/regression/musicxml/collated-files.html

JM



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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Matthew (et al.),

> Request for "rootless slash chords”

> the user will enter something like
>  \chordmode { c c/e c/g }
> to get the desired output of
>  C /E /G

Definitely on my wish list.

> with LilyPond doing some kind of translation to not show roots when there's
> a slash, but what would make sense would be for the user to enter
>  \chordtext { c /e /g }
> and get
>  C /E /G
> That would be easy by directly printing the input with only formatting
> translations (I am counting the lowercase to uppercase conversion as
> formatting) and much harder with an attempt to go to notes and back in
> between.

Why, exactly?

   input: c c/e c/g

   throughput, step 1:
   throughput, step 2: “Oh! They’re the same chords consecutively, just in 
different inversions! Let me check what the user prefers for output…”
   throughput, step 3: “They’ve selected ‘rootless slash chords for two or more 
consecutive rootless chords’ and ‘all caps’.”

   output: C /E /G

Where precisely is the problem that arises in that translation to notes?

> it sure would be easier to just type
>  \chordtext { G7alt }

Definitely on my wish list.

> We cannot expect to translate it to notes cleanly without
> more information about what it means

Agreed. But that’s easy to set up via preferences, settings, context 
properties, etc.

> but we don't need to know what it means to engrave it.

More accurately/explicitly: we don’t need to know what the symbol “G7alt” means 
in order to engrave *the symbol*.
But to engrave (or manipulate, etc.) *the chord*, we definitely *do* have to 
know what it means.

> User wants to enter:
>  \chordmode { e13 }
> and get
>  E13

Same example as above.

> User wants to engrave a chord they describe as "Gm7(b5)/F" and is told to
> type
>  g : m7.5- / f
> Note the desired output does not contain a colon or hyphen.  Using that
> suggestion, as in
>  \new ChordNames { \chordmode { g : m7.5- / f } }
> will actually engrave
>  Gø/F
> (where the ø is superscript).  User doesn't pursue it further, but this
> output does not closely resemble the requested
>  Gm7(b5)/F

That’s merely a default/stylesheet issue.
(Note: I’ve long argued for a set of chord-exception stylesheets that go beyond 
the one that’s included out of the box.)

> Counterpoint:  "but MIDI!" is a common argument for
> why chords ought to always have translations to notes.

Although I don’t currently use MIDI much, I think this is a great argument for 
chord translation.

> if we care so much about MIDI, why can't we have better MIDI support

“Patches are gratefully accepted.”

> if LilyPond is not about MIDI, chord names should not be about MIDI either.

That’s a logical fallacy. (Actually, a combination of at least two.)

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Export to ?????

[tisimst]

On Thu, May 25, 2017 at 5:52 AM, Jan-Peter Voigt [via Lilypond] <
ml+s1069038n20...@n5.nabble.com> wrote:

> just to summarize what I was talking about recently at the Music Encoding
> Conference in Tours. Yes, I am working on an API to provide a generalized
> plug for modules that are able to write MusicXML, MEI, Humdrum and others.
> I am not familiar with ABC, but maybe one can work on it *when* I can
> present some tidy code.
> In fact for my presentation I created to modules to write Humdrum and
> MusicXML. But those are not complete right now - no ties, now slurs and a
> lot more missing. But it writes the notes correctly and I can open the
> generated MusicXML with MuseScore. I will present it to the community after
> tidying up the code.
> My vision is to have an API that also allows Import modules. That way
> LilyPond can be a chain-link in a multiformat toolchain. Others can make
> use of its great typesetting and LilyPond-users (like me) can make use of
> the great tools outside Lilys world.
>

This is very exciting news! Progress is progress and I know many people who
will welcome even a fraction of conversion functionality. Can't wait to see
what you've been working on!

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Export-to-tp203320p203349.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: Chords in LilyPond

[mskala]

On Thu, 25 May 2017, Thomas Morley wrote:
> I vaguely remember such threads.
> Though, could you give some examples (or links) so it is present here as well?

Request for "rootless slash chords" from 2014 but brought up in a thread
here last month:
  https://sourceforge.net/p/testlilyissues/issues/3909/
The discussion on that issue assumes that the user will enter something
like
  \chordmode { c c/e c/g }
to get the desired output of
  C /E /G
with LilyPond doing some kind of translation to not show roots when there's
a slash, but what would make sense would be for the user to enter
  \chordtext { c /e /g }
and get
  C /E /G
That would be easy by directly printing the input with only formatting
translations (I am counting the lowercase to uppercase conversion as
formatting) and much harder with an attempt to go to notes and back in
between.

Request for "alt" notation for chords:
  http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00644.html
Here a chord symbol *does not correspond to a fixed set of notes*; it's
deliberately leaving a choice for the performer, making any translation to
notes and back difficult.  The thread includes a suggested "solution" of
  \chords {
\once\override ChordName.Text = \markup { G \super { 7 alt } }
g:7^5
  }
but it sure would be easier to just type
  \chordtext { G7alt }
Note the desired symbol does NOT contain a colon or a caret or a 5; why
are those things needed in the input?  They exist to help LilyPond decide
on a note set, which is unnecessary for engraving the symbol.  Requiring
an entire line of override code just for one symbol is a lot to ask, too;
and yes, it could be achieved with less per-chord work when there are a
lot of them by defining a chord name override or a macro, but this is
still a lot harder than just typing
  \chordtext { G7alt }
Any ambiguity in what that *engraves* is only at the level of "which parts
of this symbol does the user want superscripted?".  We cannot expect to
translate it to notes cleanly without more information about what it
means, but we don't need to know what it means to engrave it.

This thread:
  http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00600.html
User wants to enter:
  \chordmode { e13 }
and get
  E13
but instead he gets
  E9 13
The reasons for this are arcane, and attempts to "solve" it are predicated
on deciding which notes are meant to be in an E13 chord when it's not
otherwise modified - which is not a universally agreed point among
musicians, and should be completely irrelevant to the question of how to
engrave the letter "E" and the numerals "1" and "3".  At one point in the
discussion is it pointed out that he could get
  E13
by entering
  \chordmode { e:11.13 }
but I think it ought to be clear why that isn't ideal.

This thread:
  http://lists.gnu.org/archive/html/lilypond-user/2017-01/msg00248.html
User wants to engrave a chord they describe as "Gm7(b5)/F" and is told to
type
  g : m7.5- / f
Note the desired output does not contain a colon or hyphen.  Using that
suggestion, as in
  \new ChordNames { \chordmode { g : m7.5- / f } }
will actually engrave
  Gø/F
(where the ø is superscript).  User doesn't pursue it further, but this
output does not closely resemble the requested
  Gm7(b5)/F

That's just this year's worth.  Four threads in five months.

Counterpoint:  "but MIDI!" is a common argument for why chords ought to
always have translations to notes.  I use MIDI a lot myself.  But if we
care so much about MIDI, why can't we have better MIDI support - such as
the ability to enter arbitrary control changes (ideally: also raw
hexadecimal bytes, for SYSEXes and such), and to handle repeats correctly?
In order to get even halfway reasonable MIDI output, I need to write two
copies of my music, one for engraving and one for MIDI, with as much as
possible shared between them using variables (but that, in turn, harmed by
the nonexistence of any real "if" statements).  Really generating correct
MIDI from the same music used for engraving seems to be a lost cause.
The usual answer when those things are brought up is that LilyPond is
about engraving, not about MIDI, and the MIDI features are only meant for
"proofreading," not to generate high-quality MIDI that could (for
instance) be fed into a synthesizer for performance.  But if LilyPond is
not about MIDI, chord names should not be about MIDI either.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Export to ?????

[David Wright]

On Thu 25 May 2017 at 12:09:16 (+0200), Mats Behre wrote:
> If the only purpose is to export to Finale or Sibelius the score itself may 
> well be a solution - there is software like SmartScore or PhotoScore that is 
> able convert it to their formats. Of course, they cost money, so your friend 
> may not be willing to go down that path ...

There's the rub. Money.

Looking at a similar but simpler problem, converting mathematical
expressions between LaTeX and MS Word. The typical cost appears
to be around $100; double that if you want to go both ways.
That means you pay as much for one conversion mode as the entire
MS Office Suite.

Comparing: LP is free (both senses, like LaTeX); Sibelius/Finale
cost about $600. So the going rate would appear to be about $600
for conversion of a subset of functionality.

Cheers,
David.

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

Re: Export to ?????

[David Wright]

On Thu 25 May 2017 at 18:34:24 (+1000), Don Gingrich wrote:
> On Thu, 25 May 2017 09:08:35 Richard Shann wrote:
> > On Thu, 2017-05-25 at 17:45 +1000, Don Gingrich wrote:
> > > If not, then I suggest that this is a "lock-in" similar
> > > to that of some of the M$ programs.
> > 
> > There is a crucial difference, you are entitled, indeed, encouraged to
> > write such an exporter.
> > 
> > Richard
> 
> OK, 
> 
> I'll agree with that. Just feeing frustrated at the moment
> since my primary collaborator is essentially 100% Finale
> and has some idiosyncratic ideas about how music should
> be handled.
> 
> His thinking is that for Folk Music, the musician should learn
> "by ear", though as a concession, he'll allow scores. And the
> MP3 files that I generate in a work-flow that is: 
> 
> MIDI -> WAV ->MP3
> 
> Don't satisfy him. 
> 
> 

I think you need to do some straight-talking with this person.
They don't believe in scores, but think that you should have
to convert your LP scores to Finale.

They think that musicians should learn by ear, but don't
approve of your sound files.

It's easy to have idiosyncratic ideas, difficult to put them
into practice. They just want to unload the effort onto you.

Cheers,
David.

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

Re: Accidentals.sharp with number

[Emrecan]

I can write text. 

\markup{
\combine
\musicglyph #"accidentals.sharp"
\hspace #0.1
\super
\musicglyph #"eight"
}

Result: #⁸

I will write a fuction like this but I can't. Can you help me, what is
wrong?

sharptwo= #(list(make-musicglyph-markup "sharp") (make-musicglyph-markup
"eight"))
myGlyphs = #`(8/9 . \sharptwo)

\layout {
  \context {
\Score
\override KeySignature.glyph-name-alist = \myGlyphs
\override Accidental.glyph-name-alist = \myGlyphs
\override AccidentalCautionary.glyph-name-alist = \myGlyphs
\override TrillPitchAccidental.glyph-name-alist = \myGlyphs
\override AmbitusAccidental.glyph-name-alist = \myGlyphs
  }
}



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Accidentals-sharp-with-number-tp203180p203344.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: Chords in LilyPond

[Kieren MacMillan]

Hi Mats,

> Even though the average user doesn't think of an intermediate representation 
> a program that can do manipulations still needs a representation it can work 
> with.

Yes!

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Matthew (et al.),

> This is why I think the chord names -> music -> chord names flow is a problem.

The fact that this flow exists is great, IMO.
The fact that this is the *only* flow is clearly a problem.

> Real users

When talking about users, unnecessary and fallacious qualifications like “real” 
aren’t helpful to the conversation, in content or tone. I’m a "real user” — 
well, at least I *think* I am…? (pace, PKD!) — and I often [have to] "think in 
terms of a translation from input to notes and then from notes to output”.

> The natural way for typesetting of chord names to occur is by a direct mapping
> from input chord names to output chord names without going through
> the current "music" data struture consisting of notes, at all.

Well, that certainly is *one* natural way.

As I’ve pointed out in other parts of this thread, there are evidently other 
ways (e.g., starting from a music data structure) which are equally valid. 
Losing any one of the three parts of information flow — input, throughput, and 
output — would by definition be a loss of power, and a shame. Working out a way 
to manipulate and/or sidestep the throughput stage (which is essentially what 
you’re suggesting) would be a *gain* of power, and a welcome improvement.

Sincerely,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Harm,

> Am I correct you did all by chord-exceptions?

Correct.
The polychord notation requires a hack (and I never finished that portion).

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Harm,

> Could you give a pseudo-code-example demonstrating something
> for which current LilyPond fails?

Using the current codebase, how can I get the following *exactly* in Lilypond?

  C /B/Bb

Thanks,
Kieren.



Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Harm,

> could you demonstrate what you want to see printed for the above chord?

Different context(s), different output(s). See my answer to Simon’s similar 
question.

> Looks for me like you try to insist on a specific voicing
> for the C⁷ part, how _could_ this be specified?

 does exactly that, and pretty well, no?

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Simon (et al.),

>>C4/3  / Db
> Corresponding to ?

Correct.

> Adhering to standards would result in C7/Db, wouldn’t it?

*Which* standards?

1. In my musical theatre and jazz charts, you are correct: I would want C7/Db 
to be written to the chord symbol line.

2. In my new “classical”/“art” music, it’s a different story. To great relief 
from [at least some] new-music colleagues, I’ve begun including chord symbols 
in my scores — either in the score only (for conductor study) or in parts only 
(for pianists, marimba players, etc.) or both. In those contexts, I would want 
the chord symbol line to contain C4/3 / Db (where the 4/3 is written “4 over 
3”, like figured bass).

> Nor can it be output, as far as I know. What you mention, is a specific 
> voicing of a C7/E, and doesn’t chord notation by design leave exact voicings 
> unspecified?

Yes — that’s precisely my point. In a perfect world, we would be able to 
(though not forced to) indicate a voicing in the input — be that chordmode or 
<> or something entirely new — and then choose at output time what to do with 
that [extra] information: in a jazz chord chart, output the standard jazz chord 
symbol; in a musical theatre P/C score, output the standard MT chord symbol in 
the symbols, *but write out the voicing explicitly in the piano staff*; etc.

I have no idea whether this is possible, or if anyone else is trying (and 
hoping) to use chord input/throughput/output in the same way(s) as me. I’m just 
throwing my thoughts into the discussion, because Charles wants input.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Fwd: [Frescobaldi] GSoC Project "Add Support for Git Workflows to Frescobaldi" introduction (Urs Liska)

[Urs Liska]

Am 25.05.2017 um 14:04 schrieb Leszek Wroński:
>
> Guys,
>
> apologies if I've missed something obvious, but what is the intended
> place for discussing the very welcome 'Add Git support to Frescobaldi'
> project? Here? The Frescobaldi forum? The wiki (but where?)?

Well, the "natural" place for the discussion is the Frescobaldi mailing
list. But as I assume not all LilyPond/Frescobaldi users actually are
subscribed to that (and also LilyPond/not-Frescobaldi users may have
interesting views on the subject) I decided to forward it to
lilypond-user as well.

So while I hope it will not confuse people I suggest discussing the
project on either of the mailings lists.
The Wiki will probably be updated by Xin himself (or maybe also me).

>
> (I just have a minor requst: it would be convenient if we could create
> and change branches, I don't see that on the function list.)

Well, there are lots of things one could add to the list and wish, but
we have decided to limit the project plan to this "core Git workflow".
If that should be finished "too early" we will discuss what to implement
in addition. And if the GSoC project will "only" implement the current
plan there still will be a robust foundation to add more functionality
later.

>
> When it comes to the diff presentation, I'm partial to the 'Emacs +
> magit' combination (https://www.emacswiki.org/emacs/Magit )
>
We should keep that in mind. But for now we're only interested in
unstaged and staged changes.

Urs

> Good luck with the project!
>
> Cheers,
>
> Leszek.
>
> On 22 May 2017 at 18:00,  > wrote:
>
>
>
>1. Fwd: [Frescobaldi] GSoC Project "Add Support for Git
>   Workflows to  Frescobaldi" introduction (Urs Liska)
>
>
> --
>
> Message: 1
> Date: Mon, 22 May 2017 17:36:34 +0200
> From: Urs Liska >
> To: lilypond-user  >
> Subject: Fwd: [Frescobaldi] GSoC Project "Add Support for Git
> Workflows toFrescobaldi" introduction
> Message-ID:  >
> Content-Type: text/plain; charset="utf-8"
>
> Hi LilyPond users,
>
> below is a message by Wen Xin, a student who will work on adding Git
> support to Frescobaldi over the summer as his GSoC project.
>
> Please have a look at the introduction and also the Wiki page that is
> linked, we would like to have more discussion before going into actual
> implementation.
>
> Best
> Urs
>
> #
>
> Hi developers,
>
>
>
> my name is Wen Xin. I?m pursuing my master degree of computer
> science in
> Beijing University of Posts and Telecommunications. I?ve posted two
> posts before. And I guess you all know that I will be mentored by
> Urs in
> this summer while working on the projec/t Add Support for Git
> Workflows
> to Frescobaldi. /
>
>
>
> In my case, this project is to write a Git plugin for Frescobaldi. It
> will have similar functionalities like other editors? Git plugins:
>
> -  Git diff in gutter
>
>  >
>
> display Git diff in gutter
>
>
> -  Stage and discard changes in editor
>
> -  Commit in editor
>
> -  ?
>
>
> A Git initialized file will have three states: modified, staged,
> committed. Around the file?s three states, I design a Git
> work-flow. All
> the operations included will be implemented into Frescobaldi. For more
> details, you can check this wiki
>  >.
>
>  >
>
>
>
>
>
>
>
> This design is mainly discussed by me and Urs. We want to hear more
> voices from the community to help make this design become better and
> more practical. Please comment below if you have related ideas,
> thank you!
>
>
>
> Best,
>
> Wen Xin
>
> --
> Frescobaldi homepage: http://www.frescobaldi.org/
> Mailing list: http://groups.google.com/group/frescobaldi
> 
> Issue tracker: https://github.com/wbsoft/frescobaldi/issues
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> 
>  
> 

Re: Chords in LilyPond

[Simon Albrecht]

Am 25.05.2017 um 06:26 schrieb Kieren MacMillan:

Except  contains a huge amount of information that cannot 
currently be input in \chordmode (as far as I know).


Nor can it be output, as far as I know. What you mention, is a specific 
voicing of a C7/E, and doesn’t chord notation by design leave exact 
voicings unspecified?
Is this an analogous case to figured bass, where normally voicings 
aren’t specified either, but some composers (like Seb. Bach) used it to 
actually specify a particular voicing (using things like

8 3
6, 6, etc.
3
)?

Best, Simon


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

Re: Chords in LilyPond

[Simon Albrecht]

Am 25.05.2017 um 05:58 schrieb Kieren MacMillan:

Definitely not! What if I want a C7 in second inversion over a Db? In 
pseudo-harmonic-analysis code, that would be

C4/3  / Db


Corresponding to ?
Other question: You say yourself that that’s non-standard writing, and 
more harmonic analysis than normal chord symbol. Adhering to standards 
would result in C7/Db, wouldn’t it? Even if that’s more like g' bes'>…


Best, Simon

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

Re: Fwd: [Frescobaldi] GSoC Project "Add Support for Git Workflows to Frescobaldi" introduction (Urs Liska)

[Leszek Wroński]

Guys,

apologies if I've missed something obvious, but what is the intended place
for discussing the very welcome 'Add Git support to Frescobaldi' project?
Here? The Frescobaldi forum? The wiki (but where?)?

(I just have a minor requst: it would be convenient if we could create and
change branches, I don't see that on the function list.)

When it comes to the diff presentation, I'm partial to the 'Emacs + magit'
combination (https://www.emacswiki.org/emacs/Magit )

Good luck with the project!

Cheers,

Leszek.

On 22 May 2017 at 18:00,  wrote:

>
>
>1. Fwd: [Frescobaldi] GSoC Project "Add Support for Git
>   Workflows to  Frescobaldi" introduction (Urs Liska)
>
>
> --
>
> Message: 1
> Date: Mon, 22 May 2017 17:36:34 +0200
> From: Urs Liska 
> To: lilypond-user 
> Subject: Fwd: [Frescobaldi] GSoC Project "Add Support for Git
> Workflows toFrescobaldi" introduction
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Hi LilyPond users,
>
> below is a message by Wen Xin, a student who will work on adding Git
> support to Frescobaldi over the summer as his GSoC project.
>
> Please have a look at the introduction and also the Wiki page that is
> linked, we would like to have more discussion before going into actual
> implementation.
>
> Best
> Urs
>
> #
>
> Hi developers,
>
>
>
> my name is Wen Xin. I?m pursuing my master degree of computer science in
> Beijing University of Posts and Telecommunications. I?ve posted two
> posts before. And I guess you all know that I will be mentored by Urs in
> this summer while working on the projec/t Add Support for Git Workflows
> to Frescobaldi. /
>
>
>
> In my case, this project is to write a Git plugin for Frescobaldi. It
> will have similar functionalities like other editors? Git plugins:
>
> -  Git diff in gutter
>
> 
>
> display Git diff in gutter
>
>
> -  Stage and discard changes in editor
>
> -  Commit in editor
>
> -  ?
>
>
> A Git initialized file will have three states: modified, staged,
> committed. Around the file?s three states, I design a Git work-flow. All
> the operations included will be implemented into Frescobaldi. For more
> details, you can check this wiki
> .
>
> 
>
>
>
>
>
>
>
> This design is mainly discussed by me and Urs. We want to hear more
> voices from the community to help make this design become better and
> more practical. Please comment below if you have related ideas, thank you!
>
>
>
> Best,
>
> Wen Xin
>
> --
> Frescobaldi homepage: http://www.frescobaldi.org/
> Mailing list: http://groups.google.com/group/frescobaldi
> Issue tracker: https://github.com/wbsoft/frescobaldi/issues
> -- next part --
> An HTML attachment was scrubbed...
> URL:  attachments/20170522/029deb0d/attachment.html>
>
> --
>
> Subject: Digest Footer
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
>
> End of lilypond-user Digest, Vol 174, Issue 74
> **
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Export to ?????

[Jan-Peter Voigt]

Hello Don, Urs and all,

just to summarize what I was talking about recently at the Music Encoding 
Conference in Tours. Yes, I am working on an API to provide a generalized plug 
for modules that are able to write MusicXML, MEI, Humdrum and others. I am not 
familiar with ABC, but maybe one can work on it *when* I can present some tidy 
code. 
In fact for my presentation I created to modules to write Humdrum and MusicXML. 
But those are not complete right now - no ties, now slurs and a lot more 
missing. But it writes the notes correctly and I can open the generated 
MusicXML with MuseScore. I will present it to the community after tidying up 
the code.
My vision is to have an API that also allows Import modules. That way LilyPond 
can be a chain-link in a multiformat toolchain. Others can make use of its 
great typesetting and LilyPond-users (like me) can make use of the great tools 
outside Lilys world.

Jan-Peter


Am 25. Mai 2017 10:18:13 MESZ schrieb Urs Liska :
>
>
>Am 25.05.2017 um 09:45 schrieb Don Gingrich:
>> I've been looking and looking and I cannot
>> find any useful references to export file
>> formats from LilyPond.
>
>That's not completely true (see below)
>
>>
>> Now, I will agree that LilyPond's PDF output
>> is very good looking and is actually my preferred
>> sheet music, But the sad reality it that there are 
>> people who do exist who use tools other than
>> LilyPond, and that occasionally it becomes 
>> necessary to exchange files with these poor
>> benighted souls. ;-)
>
>Very true. Working with such persons or companies forces a LilyPond
>user
>to either use other tools right from the start or simply be excluded
>from that collaboration.
>
>>
>> Is there any export available from the .ly format?
>
>"any" may nail it. Frescobaldi has (if "experimental features" are
>activated") an "Export to MusicXML" option, which is, well,
>experimental. It is still pretty limited and quite fragile (makes
>assumptions about "correct" input etc.), but it *is* there at least.
>Over the summer we will have a student in the Google Summer of Code
>program who will hopefully make great progress on that.
>
>Of course MIDI is a working albeit very limited export format that has
>been available for a very long time.
>
>There have been multiple attempts at creating export functionality, but
>it *is* a tricky issue for technical reasons buried in the basic
>LilyPond architecture.
>
>Right now Jan-Peter Voigt (who might chime in to this discussion) is
>considering something like an API for a generic export infrastructure
>where exporters to various formats may be created and hooked in more
>easily.
>
>>
>> If not, then I suggest that this is a "lock-in" similar
>> to that of some of the M$ programs. 
>
>Indeed, this is the case. I *think* originally noone thought it
>necessary, LilyPond being the "engrave" tool in a Unix-like toolchain
>from one-purpose tools. This discussion has been around for many years
>by now, but due to the technical challenges and the lack of manpower no
>viable solution has been found yet.
>
>> And some
>> reasonable export that preserves a substantial
>> portion of the information might be useful.
>
>Yes.
>
>Best
>Urs
>>
>> My personal needs are simple -- ABC format
>> would probably be enough for me.
>>
>> Thanks,
>>
>> -Don
>
>-- 
>u...@openlilylib.org
>https://openlilylib.org
>http://lilypondblog.org
>
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[Thomas Morley]

2017-05-25 5:58 GMT+02:00 Kieren MacMillan :
> Hi Simon (et al.),
>
>>> added bass note
>>> inversions
>> I’m under the impression that in chord notation those are actually the same
>
> Definitely not! What if I want a C7 in second inversion over a Db? In 
> pseudo-harmonic-analysis code, that would be
>
>C4/3  / Db



Hi Kieren,

could you demonstrate what you want to see printed for the above chord?
Looks for me like you try to insist on a specific voicing for the C⁷
part, how _could_ this be specified? Or am I completely wrong
understanding your needs?


Cheers,
 Harm

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

Re: Chords in LilyPond

[Thomas Morley]

Hi Matthew,

2017-05-25 3:39 GMT+02:00  :
> On Wed, 24 May 2017, Charles Winston wrote:
>> I’m participating in the Google Summer of Code working on improving 
>> LilyPond’s internal representation of chords. The goal here is to create a 
>> data structure that will represent a chord’s semantics beyond just a list of 
>> notes in the chord. The current representation contains almost no 
>> information other than a list of notes, and we want to change this to 
>> include other semantic information, i.e. the root, quality, extensions. The 
>> current representation causes the chord naming process to infer the correct 
>> name from only the notes in the chord, which can create some problems—it 
>> would be much better to maintain the information provided by the user in 
>> chord mode about the semantics of the chord through to the naming process. 
>> Here is a rough list of semantic information I believe should be included in 
>> the data structure:
>
> Correctly printing chord names - and specifically "Why doesn't the output
> match what I typed?" - is a huge problem for users, and is a recurring
> thread on this list, so I certainly think improvements there would be a
> good thing.

I vaguely remember such threads.
Though, could you give some examples (or links) so it is present here as well?

>
> What I think is most needed is a chord-naming mode that *just prints what
> the user typed*, formatted with the fonts, spacing, and so on that we
> expect for chord names

Well, that's one of the major problems.
There seems to be no "we", even my expectations may differ from yours.

And a chord-naming mode that *just prints what the user typed* is
currently not specific enough for me.
Could you give a pseudo-code-example demonstrating something for which
current LilyPond fails?

Something at the line of

\new ChordNames \chord-input-mode { c7/des }
-> C⁷/D♭

This is not a good example, because current LilyPond can do this
without problems:
\new ChordNames \chordmode { c1:7/des  }
But you may get what I mean.


Cheers,
  Harm

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

Re: Chords in LilyPond

[Thomas Morley]

2017-05-25 6:00 GMT+02:00 Kieren MacMillan :
> Hi Harm,
>
>> Once I tried to get Brandt-Roemer namings.
>
> Have you seen my B-R stylesheet? It’s almost a complete representation.

Hi Kieren,

I don't have it stored here, but seem to remember having seen it on
the list here some time ago.
Am I correct you did all by chord-exceptions?

Cheers,
  Harm

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

Re: Export to ?????

[Mats Behre]

If the only purpose is to export to Finale or Sibelius the score itself may 
well be a solution - there is software like SmartScore or PhotoScore that is 
able convert it to their formats. Of course, they cost money, so your friend 
may not be willing to go down that path ...

Mats

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

Re: Chords in LilyPond

[Mats Behre]

On 2017-05-25 06:52, msk...@ansuz.sooke.bc.ca wrote:

On Thu, 25 May 2017, Charles Winston wrote:

On May 25, 2017, at 12:26 AM, Kieren MacMillan
 wrote: Except  contains a
huge amount of information that cannot currently be input in
\chordmode (as far as I know).

Ultimately, as long as we end up with an input system robust enough to
convey that amount of information, I don’t particularly care whether
it’s in \chordmode or whatever.

True. I think ideally we need an input mode that is stronger than
chordmode, or we at least need to improve chordmode to be able to handle

This is why I think the chord names -> music -> chord names flow is a
problem.  Real users do not think in terms of a translation from input to
notes and then from notes to output; as seen in the recurring threads on
this mailing list, most non-expert users don't even realize that "chord
mode" and the "ChordNames context" are two different things that do not
necessarily always go together.  The natural way for typesetting of chord
names to occur is by a direct mapping from input chord names to output
chord names without going through the current "music" data struture
consisting of notes, at all.


While this is true, in order to support things like transposition (which I for 
one use frequently) I think you will have to devise formats for input and 
internal representation (they may be the same) that identifies both all aspects 
of the chord and the specified notes (in this respect I only consider the root 
note of a triad a 'specified note', but that will be up to the format, really). 
If you are able to achieve that for all conceivable chords (i.e. the format has 
open-ended enough for the user to add notes) it should be possible to specify 
how each combination should be output, and usually for print this will strongly 
reflect the way the chord is entered, but the output media could also be e.g. 
MIDI. (No, I don't think this will necessarily be easy ...)

Even though the average user doesn't think of an intermediate representation a 
program that can do manipulations still needs a representation it can work with.

Mats


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

Re: SVG icons for use in Frescobaldi

[Urs Liska]

This is not only to bump the issue but to add to it.

I would like to display icons for openLilyLib packages in Frescobaldi's
(WIP) package list (see attached screenshot if this message is actually
let through to the list). My idea is to look into the package for an
icon and display a default if there isn't a specific one. I've faked
this in the screenshot by simply picking two random existing icons from
the Frescobaldi code.

As I'm really not good at it I'd be happy if someone could create a nice
default icon (SVG) that can be used as a "generic openLilyLib package"
icon. (If this person or another would be interested there could of
course also be icons for the different packages as well).

Best
Urs


Am 23.05.2017 um 11:44 schrieb Urs Liska:
> Hi all,
>
> I'm working on adding openLilyLib support for Frescobaldi. Right now I
> have a problem adding an icon file, and I don't have any clue what the
> problem is.
>
> Take the attached SVG files. Both can conveniently be opened in an image
> viewer or browser or whatever. But when loaded as an icon in Frescobaldi
> the openlilylib.svg isn't displayed. Instead lots of warnings like
>
> link glyph0-1 hasn't been detected!
> link glyph1-1 hasn't been detected!
> link glyph2-1 hasn't been detected!
> link glyph2-2 hasn't been detected!
> link glyph2-3 hasn't been detected!
>
> are displayed.
>
> I've created the SVG in Inkscape after opening a PDF and converting all
> glyphs to paths. The "missing" IDs are well present in the file, but
> obviously don't work properly when loaded as a PyQt icon.
>
> I have no idea where this comes from and would be extremely glad about
> any pointers or an updated/fixed SVG file.
>
> Best
>
> Urs
>
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: Export to ?????

[Urs Liska]

Am 25.05.2017 um 10:51 schrieb Andrew Bernard:
> Hi Don,
>
> You cannot call this 'lock-in' because nobody has forced you to use
> lilypond and you have not paid anything for it, and there is no intent
> on the part of the lilypond project to capture you and your money. I
> am unable to see how the concept of deliberate commercial 'lock-in'
> applies to open source projects.

Then maybe I suggest to call it a practical-lock-in.
As a user, if you've decided to work with LilyPond and created a project
or even a whole library of projects, you're basically locked in to using
them with LilyPond. There's currently no viable solution to take an
existing project (at least of some complexity) and pass that on to
someone who insists on using other software.

There's no commercial intent to this, OK.
And there's no restriction to create a solution, OK.

But for a *user* this doesn't make any difference, he can't reuse his
work otherwise.
And apart from the usual case of commercial publishers insisting on
Sibelius files there *are* other valid reasons why one would like to
export LilyPond files. For example getting the music into a DAW to
create *good* audio, where MIDI is still very limited. Or exporting to
Humdrum files for which there is a plethora of tools for music analysis.
And probably a lot more.

>
> Lack of export formats in lilypond is not a fair criticism, especially
> since there is no universal music notation exchange standard, and
> MusicXML is severely lacking in many respects, and is not necessarily
> going to ever become a universal standard.

I think it *is* a defect that LilyPond hasn't ever really considered
export to *any* other encoding formats important (right from the initial
conception). Yes, there is no ODF for music. But if LibreOffice wouldn't
provide export filters for Word or Excel I think lots of people wouldn't
be able to use it.
Not being able to export to MusicXML (with all its limitations) is a
hard reason not to use LilyPond for many people who might otherwise
consider it.

BTW: MEI may well become such a universal standard.

>
> If you need to export to ABC and so, then by all means start a project
> to do it and recruit participants. If you were truly locked in, such a
> path would not be possible.

But let's face it: for the average user this path is only a theoretical
option.

Urs

> One technical issue with 'downsampling' to a lesser format is what to
> do with the sophisticated constructs that ABC cannot handle.
>
> The problem with not being able to work with Finale users is just on
> of those things. Unfortunate.
>
> And sorry, I for one, even as a fanatically dedicated Linux user for
> decades or however long, do not like needless bashing of Microsoft
> with the M$ epithet. That's verging on trolling.
>
> On 25 May 2017 at 18:34, Don Gingrich  > wrote:
>
>
> > If not, then I suggest that this is a "lock-in" similar
> > to that of some of the M$ programs.
>
>
>
> Andrew
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: Export to ?????

[Andrew Bernard]

Hi Don,

You cannot call this 'lock-in' because nobody has forced you to use
lilypond and you have not paid anything for it, and there is no intent on
the part of the lilypond project to capture you and your money. I am unable
to see how the concept of deliberate commercial 'lock-in' applies to open
source projects.

Lack of export formats in lilypond is not a fair criticism, especially
since there is no universal music notation exchange standard, and MusicXML
is severely lacking in many respects, and is not necessarily going to ever
become a universal standard.

If you need to export to ABC and so, then by all means start a project to
do it and recruit participants. If you were truly locked in, such a path
would not be possible. One technical issue with 'downsampling' to a lesser
format is what to do with the sophisticated constructs that ABC cannot
handle.

The problem with not being able to work with Finale users is just on of
those things. Unfortunate.

And sorry, I for one, even as a fanatically dedicated Linux user for
decades or however long, do not like needless bashing of Microsoft with the
M$ epithet. That's verging on trolling.

On 25 May 2017 at 18:34, Don Gingrich  wrote:

>
> > If not, then I suggest that this is a "lock-in" similar
> > to that of some of the M$ programs.
>


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

Re: Export to ?????

[David Kastrup]

Don Gingrich  writes:

> On Thu, 25 May 2017 09:08:35 Richard Shann wrote:
>> On Thu, 2017-05-25 at 17:45 +1000, Don Gingrich wrote:
>> > If not, then I suggest that this is a "lock-in" similar
>> > to that of some of the M$ programs.
>> 
>> There is a crucial difference, you are entitled, indeed, encouraged to
>> write such an exporter.
>
> I'll agree with that. Just feeing frustrated at the moment
> since my primary collaborator is essentially 100% Finale
> and has some idiosyncratic ideas about how music should
> be handled.
>
> His thinking is that for Folk Music, the musician should learn
> "by ear", though as a concession, he'll allow scores. And the
> MP3 files that I generate in a work-flow that is: 
>
> MIDI -> WAV ->MP3
>
> Don't satisfy him. 
>
> 

This is only partly a problem with LilyPond.  But partly, it indeed is.

And partly, that is because programmers, the kind of people actually
improving LilyPond and its tools, often work with LilyPond because they
very much prefer working with it over other tools, so interchange tends
to be lower on the agenda than if such an agenda was based on the
"average user" rather than the "average contributor".

I still don't agree that this is anything like the walled gardens of
Microsoft.  There is no wall, just a limit to the range of the water
sprinklers.

-- 
David Kastrup

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

Re: Export to ?????

[Don Gingrich]

On Thu, 25 May 2017 09:08:35 Richard Shann wrote:
> On Thu, 2017-05-25 at 17:45 +1000, Don Gingrich wrote:
> > If not, then I suggest that this is a "lock-in" similar
> > to that of some of the M$ programs.
> 
> There is a crucial difference, you are entitled, indeed, encouraged to
> write such an exporter.
> 
> Richard

OK, 

I'll agree with that. Just feeing frustrated at the moment
since my primary collaborator is essentially 100% Finale
and has some idiosyncratic ideas about how music should
be handled.

His thinking is that for Folk Music, the musician should learn
"by ear", though as a concession, he'll allow scores. And the
MP3 files that I generate in a work-flow that is: 

MIDI -> WAV ->MP3

Don't satisfy him. 



-Don
-- 
Don Gingrich

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

Re: Export to ?????

[Richard Shann]

On Thu, 2017-05-25 at 17:45 +1000, Don Gingrich wrote:
> If not, then I suggest that this is a "lock-in" similar
> to that of some of the M$ programs.
There is a crucial difference, you are entitled, indeed, encouraged to
write such an exporter.

Richard



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

Re: Export to ?????

[Urs Liska]

Am 25.05.2017 um 09:45 schrieb Don Gingrich:
> I've been looking and looking and I cannot
> find any useful references to export file
> formats from LilyPond.

That's not completely true (see below)

>
> Now, I will agree that LilyPond's PDF output
> is very good looking and is actually my preferred
> sheet music, But the sad reality it that there are 
> people who do exist who use tools other than
> LilyPond, and that occasionally it becomes 
> necessary to exchange files with these poor
> benighted souls. ;-)

Very true. Working with such persons or companies forces a LilyPond user
to either use other tools right from the start or simply be excluded
from that collaboration.

>
> Is there any export available from the .ly format?

"any" may nail it. Frescobaldi has (if "experimental features" are
activated") an "Export to MusicXML" option, which is, well,
experimental. It is still pretty limited and quite fragile (makes
assumptions about "correct" input etc.), but it *is* there at least.
Over the summer we will have a student in the Google Summer of Code
program who will hopefully make great progress on that.

Of course MIDI is a working albeit very limited export format that has
been available for a very long time.

There have been multiple attempts at creating export functionality, but
it *is* a tricky issue for technical reasons buried in the basic
LilyPond architecture.

Right now Jan-Peter Voigt (who might chime in to this discussion) is
considering something like an API for a generic export infrastructure
where exporters to various formats may be created and hooked in more easily.

>
> If not, then I suggest that this is a "lock-in" similar
> to that of some of the M$ programs. 

Indeed, this is the case. I *think* originally noone thought it
necessary, LilyPond being the "engrave" tool in a Unix-like toolchain
from one-purpose tools. This discussion has been around for many years
by now, but due to the technical challenges and the lack of manpower no
viable solution has been found yet.

> And some
> reasonable export that preserves a substantial
> portion of the information might be useful.

Yes.

Best
Urs
>
> My personal needs are simple -- ABC format
> would probably be enough for me.
>
> Thanks,
>
> -Don

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Export to ?????

[Don Gingrich]

I've been looking and looking and I cannot
find any useful references to export file
formats from LilyPond.

Now, I will agree that LilyPond's PDF output
is very good looking and is actually my preferred
sheet music, But the sad reality it that there are 
people who do exist who use tools other than
LilyPond, and that occasionally it becomes 
necessary to exchange files with these poor
benighted souls. ;-)

Is there any export available from the .ly format?

If not, then I suggest that this is a "lock-in" similar
to that of some of the M$ programs. And some
reasonable export that preserves a substantial
portion of the information might be useful.

My personal needs are simple -- ABC format
would probably be enough for me.

Thanks,

-Don
-- 
Don Gingrich

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

Re: Permission for music

[David Kastrup]

msk...@ansuz.sooke.bc.ca writes:

> On Wed, 24 May 2017, Simon Albrecht wrote:
>> > This is one reason that putting advertising for the LilyPond Web
>> > site in every PDF document by default may not be such a great idea.
>> > It makes LilyPond appear to have a meaningful connection with the
>> > content.
>>
>> Only if you overlook that the tagline specifically says the music was
>> _engraved_ with LilyPond, which does not tell anything about any
>> connection between LilyPond and the _content_.
>
> But people do overlook that, as this thread demonstrates.

People vote for Trump and Brexit given the chance.  At some point of
time, you just need to give them all the info and pray.  You cannot hope
to save them from themselves.

-- 
David Kastrup

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