> -- Forwarded message --
> From: Charles Winston
> To: lilypond-user@gnu.org
> Subject: Chords in LilyPond
> Hi LilyPond users,
> I’m participating in the Google Summer of Code working on improving
LilyPond’s internal representation of chords.
T
Hi Ivan,
>> How is it "wrong" for the chord to [additionally]
>> include the information 'root = a'?
>
> In some instances the root could be C and the A would be a passing tone.
> In other instances, calling any of those four tones a root would
> have no meaning. It would depend on the context.
Ivan Kuznetsov writes:
> Kieren MacMillan wrote:
>>
>> How is it "wrong" for the chord to [additionally] include the
>> information 'root = a'?
>
> In some instances the root could be C and the A would be a passing tone.
> In other instances, calling any of those four tones a root would
> have
Kieren MacMillan wrote:
>
> How is it "wrong" for the chord to [additionally] include the
> information 'root = a'?
In some instances the root could be C and the A would be a passing tone.
In other instances, calling any of those four tones a root would
have no meaning. It would depend on the c
Hi Ivan,
Thanks for your input on this important thread.
> This "every chord can/should be given a name" hypothesis
> is a popular/amateur musician idea that does not exist
> in the concert/conservatory musician world.
Not every chord can or should be given a name, of course.
That being said, I
I realize I am late on this thread, and I have not even read
the other responses, but I will try to explain why adding
"semantics" to a chord data structure is a mistake.
This "every chord can/should be given a name" hypothesis is a
popular/amateur musician idea that does not exist in the
concert/
On 29.05.2017 21:00, Peter Gentry wrote:
However this idea would surely fall on stony ground in the context of
atonal or twelve note music.
Neither of which would ever use chord entry or even chord names.
Best, Simon
___
lilypond-user mailing li
On 30 May 2017 at 01:16, Henning Hraban Ramm wrote:
> Am 2017-05-29 um 08:24 schrieb David Kastrup :
>
> > Johan Vromans writes:
> >
> >> On Mon, 29 May 2017 14:24:52 +1000, Vaughan McAlley
> >> wrote:
> >>
> >>> Does anyone actually use MIDI from the chord performer?
> >>
> >> I do. Although t
Hi Carl,
> I had not heard of quartic chords before reading this email (as I've
> mentioned before, I'm a music novice). It was very interesting for me to
> study quartic chords.
They form a large part of my harmonic (composition and arranging) language.
> But in my web search and following lin
Am 29.05.17 um 15:28 schrieb Carl Sorensen:
I had not heard of quartic chords before reading this email (as I've
mentioned before, I'm a music novice). It was very interesting for me to
study quartic chords.
But in my web search and following links, I never found anything that
approached a no
On 29/05/17 06:04, Carl Sorensen wrote:
> Charles's project is not to solve all three of these. In fact, his
> project is not to completely solve any one of them. Rather, his problem
> is to determine how best to save the semantics, so that assuming the
> semantics are properly entered in chordmo
Am 2017-05-29 um 08:24 schrieb David Kastrup :
> Johan Vromans writes:
>
>> On Mon, 29 May 2017 14:24:52 +1000, Vaughan McAlley
>> wrote:
>>
>>> Does anyone actually use MIDI from the chord performer?
>>
>> I do. Although the voicing of the chords is not what a normal player
>> would do, it i
Hi Peter,
> I have struggled to understand what is being discussed.
Sorry for that. Hopefully, when the project is *implemented*, the user
interface won’t provide a barrier to understanding.
> Am I correct in seeing “semantics” in this way ?
We are using semantics in the sense of “what does t
On 5/24/17 4:51 PM, "Kieren MacMillan" wrote:
>
>> Some things that should be thought about:
>> Is the 7 an extension? Or included in the quality the chord? Or maybe
>>something else?
>
>Since we¹re starting from the ground up, can we not assume triadic
>harmony for the input (even if the ou
On 5/29/17 5:58 AM, "Peter Gentry" wrote:
>I have been intrigued by the highly technical correspondence on this
>topic. However I have struggled to understand what is being discussed.
>Other links such as
>http://motools.sourceforge.net/chord_draft_1/chord.html describe in some
>detail the str
2017-05-29 11:44 GMT+02:00 Thomas Morley :
> (2)
> Finally something like the terminal-output of the fake below is aimed at:
>
> chrd-test-III =
> \chordmode {
> \displayMusic
> \withMusicProperty semantics
> #`((root . ,#{ c #})
> ;; or?
> (root . "C")
Erhm, should
2017-05-29 7:04 GMT+02:00 Carl Sorensen :
> On 5/28/17 5:53 PM, "Thomas Morley" wrote:
>
>>
>>
>>Though, why adding a Œsemantics entry to the EventChord?
>>I'd suggest to write such an interpreter as a procedure which works on
>>the pitchlist ignatzek-chord-names currently has to work with
>>(incl
Johan Vromans writes:
> On Mon, 29 May 2017 14:24:52 +1000, Vaughan McAlley
> wrote:
>
>> Does anyone actually use MIDI from the chord performer?
>
> I do. Although the voicing of the chords is not what a normal player
> would do, it is okay for checking scores and practising.
If the voicing we
On Mon, 29 May 2017 14:24:52 +1000, Vaughan McAlley
wrote:
> Does anyone actually use MIDI from the chord performer?
I do. Although the voicing of the chords is not what a normal player would
do, it is okay for checking scores and practising.
-- Johan
__
On 5/28/17 5:53 PM, "Thomas Morley" wrote:
>
>
>Though, why adding a Œsemantics entry to the EventChord?
>I'd suggest to write such an interpreter as a procedure which works on
>the pitchlist ignatzek-chord-names currently has to work with
>(including bass/inversion-info). Then write a printing-f
On 29 May 2017 at 09:53, Thomas Morley wrote:
> This sounds like you want to write a chord-analyser or probably a
> better wording would be chord-interpreter.
>
I think it’s impractical to use chord analysis on anything but anything but
simple chords. Power users like Kieren and Robert will want
)
2017-05-28 17:18 GMT+02:00 Charles Winston :
> Hi all,
>
> There have been some great discussions about new chord functionality you’d
> like to see in LilyPond. The first step is defining the internal
> representation. From there, I think all these issues can be much more easily
> solved. We
On 28/05/17 17:54, Kieren MacMillan wrote:
>> the contexts that need the semantic information shouldn’t need note
>> information, and the contexts that need note information don’t need semantic
>> information.
> As someone who uses chords both for their note and semantic information
> simultane
Hi Charles,
> The first step is defining the internal representation. From there, I think
> all these issues can be much more easily solved.
That seems (intuitively) correct to me.
> Let me know what more should be added to this list.
How do you represent polychords?
How do you represent chord
Hi Charles,
> My intention is definitely not to create a representation where the notes and
> semantics cannot be passed together into different contexts
Good! That’s important.
It’s also likely critical (as David brought up) to either completely disallow
the entry of notes and semantics which
> On May 28, 2017, at 12:55 PM, Kieren MacMillan
> wrote:
>
> Hi Charles (et al.),
>
>> Storing this information in the NoteEvents is clunky in my opinion
>
> Possibly…
>
>> and defeats the purpose of this project
>
> I don’t see how that necessarily/logically follows…?
>
>> the numerous
Hi Charles (et al.),
> Storing this information in the NoteEvents is clunky in my opinion
Possibly…
> and defeats the purpose of this project
I don’t see how that necessarily/logically follows…?
> the numerous benefits of an internal representation which understands the
> semantics of a chord
Hi Charles,
how good of you to send a summary of this thread. I was very interested
in it as you wrote the first mail but couldn't reply right away. And
when I could, the thread had already grown so huge, I just could not
keep up all posts.
So it might well be that what I write has already bee
Charles Winston writes:
> Hi David,
>
>>> Hi all,
>>>
>>> There have been some great discussions about new chord functionality you’d
>>> like to see in LilyPond. The first step is defining the internal
>>> representation. From there, I think all these issues can be much more
>>> easily solved
Hi David,
>> Hi all,
>>
>> There have been some great discussions about new chord functionality you’d
>> like to see in LilyPond. The first step is defining the internal
>> representation. From there, I think all these issues can be much more easily
>> solved. We have the EventChord structure,
Charles Winston writes:
> Hi all,
>
> There have been some great discussions about new chord functionality you’d
> like to see in LilyPond. The first step is defining the internal
> representation. From there, I think all these issues can be much more easily
> solved. We have the EventChord st
Hi all,
There have been some great discussions about new chord functionality you’d like
to see in LilyPond. The first step is defining the internal representation.
From there, I think all these issues can be much more easily solved. We have
the EventChord structure, which contains an ‘articulat
On 25/05/17 05:52, msk...@ansuz.sooke.bc.ca wrote:
> 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.
Until you want to transpose th
On 25/05/17 02:39, msk...@ansuz.sooke.bc.ca wrote:
> 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 - not translating it to an "internal
> representation" of notes plus extra
Hi Matthew,
> That in fact is what I do in my own engraving. It works pretty well; not
> perfectly because the spacing and fonts aren't the same as would be
> produced by the ChordNames context.
You could program it to do so…
> this approach isn't discoverable for a user who only reads the inst
Hi Matthew (et al.),
> I'm describing what I have seen on the list. Users frequently come here
> to ask "When I typed this chord symbol, why was something else engraved?".
> They do not ask that about single notes.
Demonstrably untrue. I’ve witnessed and been involved in *lots* of discussions
w
On Fri, 26 May 2017, Kieren MacMillan wrote:
> And I must say, I see his point: your implication seems to be that the
> tolerance the “ordinary user” apparently has for working in a
> notoriously uninviting and unfriendly [other people’s words, not mine!]
> non-GUI-based batch-processed music engra
On Fri, 26 May 2017, Kieren MacMillan wrote:
> You do know that you’re not *forced* to use ChordNames, right? (Of
> If you want to type something and simply have it appear as you typed it
> (i.e., with no use or need for manipulations like transposition), why
> not just use Lyrics? It already does
Hi Matthew and Simon,
>> { c4 } does not print a ‘4’
> That's not a chord.
Do you both really have that much difficulty figuring out what the other is
saying?
(Don’t bother answering — that was a rhetorical question.)
Simon isn’t saying, suggesting, or even implying that c4 is a chord. He’s
sa
Am 26.05.2017 um 20:53 schrieb msk...@ansuz.sooke.bc.ca:
On Fri, 26 May 2017, Simon Albrecht wrote:
Am 26.05.2017 um 15:48 schrieb msk...@ansuz.sooke.bc.ca:
On Fri, 26 May 2017, Simon Albrecht wrote:
Well, input syntax does not equal desired output.
For ordinary users, it does.
I have no ide
On Fri, 26 May 2017, Simon Albrecht wrote:
> Am 26.05.2017 um 15:48 schrieb msk...@ansuz.sooke.bc.ca:
> > On Fri, 26 May 2017, Simon Albrecht wrote:
> > > Well, input syntax does not equal desired output.
> > For ordinary users, it does.
>
> I have no idea what you’re talking about.
Chords. As th
Hi Simon,
> Am 26.05.2017 um 15:48 schrieb msk...@ansuz.sooke.bc.ca:
>> On Fri, 26 May 2017, Simon Albrecht wrote:
>>> Well, input syntax does not equal desired output.
>> For ordinary users, it does.
>
> I have no idea what you’re talking about.
He’s saying that, because chord symbols are essen
Am 26.05.2017 um 15:48 schrieb msk...@ansuz.sooke.bc.ca:
On Fri, 26 May 2017, Simon Albrecht wrote:
Well, input syntax does not equal desired output.
For ordinary users, it does.
I have no idea what you’re talking about. { c4 } does not print a ‘4’,
nor the letter ‘c’. It would appear that y
Hi all,
> I think most readers would interpret it as "C with A in the
> bass" (and why that chord is not called A-minor-seventh, left unclear).
Agreed.
> This would be a problem for a system like current LilyPond that insists on
> translating it to notes and back, because the internal representa
Hi Matthew,
> On Fri, 26 May 2017, Simon Albrecht wrote:
>> Well, input syntax does not equal desired output.
> For ordinary users, it does.
You do know that you’re not *forced* to use ChordNames, right?
(Of course, I realize we’re currently talking about improving that part of
Lilypond, and hen
On Fri, 26 May 2017, Henning Hraban Ramm wrote:
> I would manually write C/a if I want to let the player chose between c major
> and a minor.
> (Lowercase letters for minor chords needed a while to be possible with
> LilyPond, but they are.)
It's fine if you want to write that and you and the re
On Fri, 26 May 2017, Simon Albrecht wrote:
> Well, input syntax does not equal desired output.
For ordinary users, it does.
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
___
lilypond-user
On Fri, 26 May 2017, Thomas Morley wrote:
> (Close to) all requested stuff is possible even right know. Ofcourse
The problem is not that LilyPond cannot print the desired symbols. The
problem is that the input to print those symbols does not match the
output, and the mapping from input to output
Am 2017-05-25 um 16:46 schrieb msk...@ansuz.sooke.bc.ca:
> 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
> \chord
Am 2017-05-25 um 06:03 schrieb Kieren MacMillan :
>> 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 - not translating it to an "internal
>> representation" of notes plus ex
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
'
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 o
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 transpo
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 wou
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/
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
‣
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 “
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
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: w
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 t
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
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
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
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 woul
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 be
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 corr
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
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 enou
> On May 25, 2017, at 12:26 AM, Kieren MacMillan
> wrote:
>
> Hi Charles,
>
>>> Which mode of input?
>>> \chordmode { c1:7 }
>>> or
>>> { 1 }
>>
>> I think \chordmode will be the most useful form of input, because that way
>> we know the user's intentions with the chords. It would be tough
Hi Charles,
>> Which mode of input?
>> \chordmode { c1:7 }
>> or
>> { 1 }
>
> I think \chordmode will be the most useful form of input, because that way we
> know the user's intentions with the chords. It would be tough to infer the
> semantics from just the note input, which is essentially
On May 25, 2017, at 12:09 AM, Kieren MacMillan
wrote:
>> how much should we base this data structure on the current mode of input?
>
> Which mode of input?
>
>\chordmode { c1:7 }
>
> or
>
>{ 1 }
I think \chordmode will be the most useful form of input, because that way we
know th
Hi Charles,
> we certainly want the output to match the input.
An important question is: is it a one-to-one relationship?
> how much should we base this data structure on the current mode of input?
Which mode of input?
\chordmode { c1:7 }
or
{ 1 }
??
> certain aspects of input can
Hi Matthew (et al.),
> 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 - not translating it to an "internal
> representation" of notes plus extra data as LilyPond "music" at a
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
In my compositions (especially musi
Hi Harm,
> Once I tried to get Brandt-Roemer namings.
Have you seen my B-R stylesheet? It’s almost a complete representation.
> The criteria which pitches are regarded to set extensions, etc are different
> enough from Ignatzek
> that it would have resulted in a complete rewrite of the
> chord
> On May 24, 2017, at 9:40 PM, "msk...@ansuz.sooke.bc.ca"
> wrote:
>
>> 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
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
2017-05-25 0:17 GMT+02:00 Charles Winston :
> I would love to hear any ideas from the user community about this. And beyond
> the specific issues I’m talking about here, what aspects of LilyPond’s
> support for chords do you believe should be improved or changed?
I think the greatest problem is
2017-05-25 0:54 GMT+02:00 Simon Albrecht :
> Am 25.05.2017 um 00:17 schrieb Charles Winston:
>>
>> added bass note
>> inversions
>
>
> I’m under the impression that in chord notation those are actually the same
> – I don’t think that there is a conceptual difference between C/E and C/D in
> chord n
2017-05-25 0:17 GMT+02:00 Charles Winston :
> Hi LilyPond users,
>
> 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
> n
Am 25.05.2017 um 00:17 schrieb Charles Winston:
How do we deal with semantics that may overlap between these categories? For
example: is a sharp-5 an alteration or just an augmented chord?
Off the top of my head: Both should be possible input methods, but
internally represented the same. How
Am 25.05.2017 um 00:17 schrieb Charles Winston:
added bass note
inversions
I’m under the impression that in chord notation those are actually the
same – I don’t think that there is a conceptual difference between C/E
and C/D in chord notation. But it may be that instead of this pragmatic
way
Hello Charles,
> I’m participating in the Google Summer of Code working on improving
> LilyPond’s internal representation of chords.
As someone who uses chord names extensively, I’m thrilled that you’re tackling
this!
> The goal here is to create a data structure that will represent a chord’s
Hi LilyPond users,
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
PabloZum skrev:
but D13 appears as D9/add13.
That looks like a bug.
I'll report it.
For now you can use d:11.13
What to do for A7b9?
a:9-
There should be a list somewhere, like:
I agree.
http://lilypond.org/web/devel/participating/documentation-adding
:-)
-Rune
___
out a code file I'll
probably get this wrong, but here goes:
a:7.9+.13-
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re:jazz chords in LilyPond Date:
Thu, 19 Jul 2007 14:33:58 -0300
Thank you, Carl and Tao. I'll try both ideas.
I've found that LilyPond *can* print many jazz
Thanks, Tao, but that's the Chord Name Chart I just mentioned. A longer chart
is here:
http://lilypond.org/doc/v1.9/Documentation/user/out-www/lilypond/Chord-name-chart.html
However, this chart is misleading. Take the case below.
<<
\new ChordNames {
\set chordChanges = ##t
An: lilypond-user@gnu.org
Betreff: Re:jazz chords in LilyPond
> Thank you, Carl and Tao. I'll try both ideas.
>
> I've found that LilyPond *can* print many jazzy chord names after all,
> though some of them look a little unwieldy.
>
> The Chord Name Chart in the Lil
Thank you, Carl and Tao. I'll try both ideas.
I've found that LilyPond *can* print many jazzy chord names after all, though
some of them look a little unwieldy.
The Chord Name Chart in the LilyPond Manual lists the resulting printed view of
the chord names but it does not list the actual words
orensen <[EMAIL PROTECTED]>
An: lilypond-user@gnu.org
Betreff: Re: jazz chords in LilyPond
> PabloZum terra.com.br> writes:
>
> >
> >
> > I have developed my own chord name font, "Cifrado", which I use to print
> > scores in other programs. With it
PabloZum terra.com.br> writes:
>
>
> I have developed my own chord name font, "Cifrado", which I use to print
> scores in other programs. With it, I'm able to print complex jazz chords with
> fewer keystrokes (e.g., "A7#9b13" is input just with "ax;").
If you want to keep the musical meani
I have developed my own chord name font, "Cifrado", which I use to print scores
in other programs. With it, I'm able to print complex jazz chords with fewer
keystrokes (e.g., "A7#9b13" is input just with "ax;"). I've been trying to make
OooLilyPond use this font for chord names in OpenOffice. I'
Hi
I'm trying to tremolo two piano chords but the tremolo beams are colliding with
the notes, and would also look better slanted (as opposed to horizontal). Can
anyone help with this?
<< {s4\pp\< s2 s4\ff\! } \\
{\repeat "tremolo" 16 { 32 32 }} >>
Many thanks
Stuart Taylor
___
HG> Is this a thing for later releases, or is there a solution.
I've haven't an answer for your question, but anybody here will ask
you to upgrade to the latest version (1.6.1) which can be found in
binary releases and source code at the Lilypond website:
http://www.lilypond.org
The address o
94 matches
Mail list logo
