bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support accordion with standard bass


From: Carl Sorensen
Subject: Re: Support accordion with standard bass
Date: Sun, 13 Jan 2008 21:33:20 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

David Kastrup <dak <at> gnu.org> writes:

> 
> 
> Accordion with standard bass is not well-supported in Lilypond.

David,

This is a nice description of accordion notation.  Such a discussion would
normally take place on user, not on bugs.  Since I'm working on the Gmane
interface, I can't easily forward it there.  You might want to.

<snip>
> 
> Ok, what does this imply for Lilypond?  Basically, we have three areas
> that are concerned: entry, layout, midi.
> 
> Entry: since bass note and chord constituents may sound differently,
> they must always be distinguishable.
> 
> Now Lilypond already has a chord concept, and figuring out an accordion
> bass from a non-accordion specific input is probably fine as long as one
> can figure out the bass note.  With an accordion, chord inversions don't
> actually count.  So the algorithm probably would work by subtracting the
> bass note from the sounded notes, then taking the chord that matches the
> largest number of the remaining notes (ignoring the octave and not
> sounding any note not in the original chord).  A diminuished chord
> should probably (optionally?) also remove its non-existent fifth (while
> not using it for matching purposes).  It should be configurable whether
> a seventh chord must have a match for its straight fifth or not as this
> is obviously dependent on the instrument.  Similarly, it should be
> possible for accordions with a different row layout to get matched to
> existing music.  When no more chord fits, the rest may possibly filled
> in with bass notes or left alone.
> 
> An algorithm like that would probably be able to synthesize most Jazz
> harmonies.

The code for calculating notes from chord names is written in scheme, and could
be modified by someone who knows as much as you do about how it works.  You'd
need to learn Scheme, but it's not impossible to do...

> 
> I think that the existing chord/bass note system should mostly be
> tolerable for entry here, except that for the accordion, chords may get
> sounded without a bass note, and bass notes without a chord.
> 
> One notable information that is often present is whether a bass note is
> to be played on the second (main) row, or on the first row (the bass row
> containing thirds).  Sort of fingering information, but pretty much
> always specified.
> 
> Anyway, let us come to the output.  Here is where things are getting
> really messy.

My observation is that if you want to have some special kind of output notation,
you'll probably need to write it yourself.  This has both good and bad points. 
Bad, you have to do the work.  Good, you get exactly what you want.  This is
what got me to do the fret diagrams code -- I knew what I wanted and I figured
out how to get it.

> 
> With the score, we have basically two flavors: German and American
> Accordion Association.  The main difference is that in the German
> notation chords are written out, whereas AAA notation is quite closer to
> numbered bass notation in that a chord is written as its principal base
> note (discounting inversions!) with possibly a letter above (like an
> accidental, the letters tend not to get repeated).  Letters are M for
> major (the default, so only needed for dissolving a previously given
> different letter), m for minor, 7 for seventh and d for diminuished.  So
> the AAA notation is less cluttered (with fewer noteheads), but harder to
> transfer to other instruments.  The principal bass note is put below the
> middle line from the bass clef (C position and lower), the chords on the
> middle line and above.  This division is hard in order to make the
> notation unique: when transposing, one needs to wrap around the octaves.

AAA notation seems to me to be easy to do with a note and a markup (or perhaps
two notes)

> 
> Now we come to the really fuzzy notation, the German one.  Here the
> chords are written out in notes, and usually also with chord/bass names
> below the staff.  The principal bass/chord division is the same, and
> chords are written out in the lowest place where they fit disregarding
> chord inversions.  That is sort of a canonical notation.  The fuzz comes
> into play since writing out the chords makes it possible to play it on
> other instruments, most notably a free bass accordion.  And then chord
> inversions do matter.  Since chords and bass notes are distinguishable
> by the number of stacked notes, their division tends to be weakened:
> bass lines will at times not be wrapped around, and chords may reach
> below the middle line when the equivalent free bass would finger them
> there.

This is probably also not too difficult to do -- all you have to do is write the
scheme code to get the correct notes; all of the engraving is handled
automatically.  You've described the rules in words, so you could probably do it
in scheme.
> 
> Whether one wants to have bass notes wrap around or chords to change to
> a different inversion when transposing is certainly user/writer choice.
> Also the writer needs to have a way to say "don't move my bass
> notes/chords to different places" while the default would likely
> normalize both chords and basses.
> 
> Now to the Midi output: to make things even more annoying, the bass
> system has just 12 notes, as told.  But where the wraparound in the
> notation occurs at C, the wraparound in the most common instrument type
> occurs at E (that is, E is the lowest note, Eb the highest).  I think
> that some instruments might wrap around somewhere else, but...
>

I think that you should be able to detect in your scheme code whether you're in
midi mode or not, so your wraparound code could handle the midi properly as
being different from notation.
 
> So if we want to cater for life-realistic Midi, we might need to wrap
> around against some other thresholds with regard to chords/inversions
> than we do in the notation.
> 
> I won't vouch for all of the details, but that is the gist.  Note that
> one can produce something like that with lilypond visually, but
> 
> a) one has to code the chords manually which means that it is not
> trivial to produce output for, say, accordeon and piano and figured bass
> from the same input.
> 
> b) chords and bass notes don't stay in their designated space when
> transposed.
> 
> c) when chords are not written out, the midi output will not correspond
> with the actual sound.
> 
> Any thoughts how much work would be involved in tackling any of those
> three problems, and what mechanisms that are already in place could be
> get used favorably?  I would be willing considering to sponsor some
> development here but one should flesh out what is sensible here in
> advance, and how much work would need to get put in what area.

AFAICT, right now there is nobody who is willing to do sponsored work.  Han-Wen
did most (all) of it in the past, and now he has a day-job, so his time with
LilyPond is greatly reduced.

I hope I haven't discouraged you.  I think you'll find that it's not impossible
to learn enough scheme to modify the notation in LilyPond.  It's my experience
that the scheme code is the easiest to modify, once you get used to prefix
notation and lots of parentheses.  And it's always great to get somebody new
with the ability to hack on LilyPond.

Carl Sorensen





reply via email to

[Prev in Thread] Current Thread [Next in Thread]