lilypond-user
[Top][All Lists]
Advanced

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

Re: Change stem direction based on position of note in staff?


From: Stefano Antonelli
Subject: Re: Change stem direction based on position of note in staff?
Date: Sat, 31 Aug 2024 23:36:55 +0000
User-agent: Evolution 3.36.5-0ubuntu1

On Sat, 2024-08-31 at 22:31 +0200, Lukas-Fabian Moser wrote:
> Hi Stefano,

Hi Lukas,

> > What I want to achieve in the end are different voicings for drum
> > notation using the same input notes.  The different voicings are
> > described here:
> > 
> > https://www.onlinedrummer.com/blogs/drum-lessons/introduction-to-voicing-in-drum-notation
> > 
> > From that web page is a good image showing what the different
> > voicings
> > look like.  There are 4 songs, each notated in the 3 common
> > voicings.
> 
> Thanks, it's clear to me now.
> 
> This is an fun, albeit non-trivial problem. It seems to me that the
> "natural" representation of a drum pattern would be something akin to
> ASCII drum tabs:
> 
> C |----------------|----------------|----------------|----------x--
> ---|
> R |x-x-x-x-x-x-x-x-|x-x-x-x-x-x-x-x-|x-x-x-x-x-x-x-x-|x-x-x-x-x---x-
> x-|
> S |----o--o-o--o--o|----o--o-o--o--o|----o--o-o----o-|-o--o--o-o--
> --o-|
> B |o-o-------oo----|o-o-------oo----|o-o-------o-----|--oo------o--
> ---|
> 
> This information should than be combined into one or two voices, the
> latter according to one of several rules (hands vs. feet, cymbals vs.
> drums etc.)

Yes, but it gets more complicated.  For example, this is something I
transcribed in drumburp:

Cr|X-------|--------|X-------|--------|
Hh|--x-x-x-|x-x-x-x-|--x-x-x-|x-x-x-x-|
HT|--------|--------|--------|----oooo|
MT|--------|--------|--------|-----o--|
Sn|--o---o-|--o---o-|--o---o-|--o---o-|
FT|--------|--------|--------|--------|
Bd|o---oo--|o---oo-o|o---oo--|o---oo-o|
   1+2+3+4+ 1+2+3+4+ 1+2+3+4+ 1+2+3+4+ 

HT, MT, FT are the toms (high, mid, and floor).  Cr is a crash cymbal,
Hh is hihat, Sn is Snare and Bd is kick drum.  Not shown, but also
common are pedal hihat and other cymbals, cowbells, woodblocks,
triangles, etc.  Each instrument may get it's own line, but sometimes
different note heads can indicate different instruments on the same
line.

I don't want to enter notes that way though.  Typing tabs is not fun.
 Aligning all the ascii sucks.  That's why drumburp is a nice program
because graphically, it sucks much less.

Better would be some lilypond like syntax with different lines for the
different instruments like the tab I wrote above.

> What's conceptually easy (and easy to implement) is:
> 
> - going from LilyPond voices to a "tabular" representation,
> - group the kicks in the tabular representation into voices according
> to whichever rule,
> - make LilyPond understand a tab notation like the one above.

Right.

> What's *not* easy is:
> 
> - convert a series of zero-time events (kicks, combined kicks) into
> musical notation.

It's not just that.  It's interweaving the kick and combined kicks with
the other instruments grouped within that same voice.  This is why
\partcombine doesn't work and I'm not sure a \drumcombine would be able
to do it either.

> The reason is that one would have to define rules about how to
> represent any possible constellation of kicks in musical notation,
> since there are plenty of possibilites regarding the choice of dots,
> ties and rests. The following rhythms are written completely
> different, yet they are identical in terms of "kicks":

Agreed.  But as I said it's not just about getting the kick notes
correct.  Take for example something easy:

Cr|X-------|
Hh|--x-x-x-|
Sn|--o---o-|
Bd|o---o---|
   1+2+3+4+

Here if you have the bass drum grouped with snare (drums and cymbals),
then each beat is on quarters:

bd4 sn4 bd4 sn4

But if the kick drum is all by itself (hands and feet), then you could
have:

bd2 bd2

Although that would be weird.  I think:

bd4 r4 bd4 r4

would be more appropriate.

> Which of these notations should be used? (Of course some are more
> convenient than others, but there are various reasonable choices.)
> The problem isn't made much easier when starting with a given voice-
> like musical notation, since when combining multiple voices into one,
> notes of a given duration have to be split, leading to the same
> decision problems.

Agreed.  But there are common ways to do it.  Perhaps those common ways
could be used to steer decisions.

If you're interested in how one project has tackled it, have a look at
drumburp:

<https://whatang.org/>

Specifically this file (also attached):

<
https://github.com/Whatang/DrumBurp/blob/1.1.2/src/Notation/lilypond.py
>

That's what I've started looking at when I have time.  Though my python
isn't very good.

But drumburp doesn't do it well.  It uses drums and cymbals (yuck) and
it doesn't look like proper drum notation (beams are not flat).  Even
though I knew about the lilypond export, I didn't like the result and
didn't use it.

Revisiting it now, I could probably fix the ugliness easily.  If I can
change how the different instruments are assigned to \voiceOne and
\voiceTwo, then it might be a good way for me to get tab notation into
lilypond format.  Although I would still like to use a lilypond like
notation instead of the graphical entry of drumburp.

When I understand what lilypond.py is doing, then perhaps it can be
massaged to produce the right output.

Just while looking at drumburp, there are a number of example tabs of
whole songs in the git repo.  I've attached the output of one of the
songs in lilypond format, tab format, and pdf.  In the lilypond file, I
see some interesting functions defined:

#(define (rest-score r) ...
#(define (merge-rests-on-positioning grob) ...

But I don't yet know what they do.

Attachment: semi-charmed-life.ly
Description: semi-charmed-life.ly

Attachment: semi-charmed-life.pdf
Description: semi-charmed-life.pdf

Attachment: semi-charmed-life.txt
Description: semi-charmed-life.txt

Attachment: lilypond.py
Description: lilypond.py


reply via email to

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