lilypond-devel
[Top][All Lists]
Advanced

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

Re: Code review/advice for accordion registers


From: Carl Sorensen
Subject: Re: Code review/advice for accordion registers
Date: Tue, 10 Nov 2009 12:07:59 -0700

David,

Congratulations on putting this together.


On 11/10/09 8:47 AM, "David Kastrup" <address@hidden> wrote:

> 
> 
>> I'm not topposting
> 
> after getting some advice here, I tried coding some accordion register
> setting stuff.  I have little enough available input on the best
> available options and names, no idea whatoever about Bayan
> (consequently, no Bayan bass here), and have failed to work with
> context-sensitive settings.  For example, I'd like to have something
> like Voice.registerInstrument which I can independently set per Voice
> and which is inherited into subvoices and can be used with \set,
> \override etc.  No idea how to do this.

I don't think that there is any "inheritance" per se in LilyPond.  Voices
are all bottom contexts.  So there aren't any subvoices.  Voices are all
"peers" at the bottom context level, IIUC.

> 
> It also feels unclean to have to define this as macro, but short of
> using macros, I have no idea how to feed the requisite material into
> define-markup-command, itself a macro.  All of this looks pretty ugly.

If you look at scm/fret-diagrams.scm and scm/harp-pedals.scm you'll see that
we didn't define these complex markups as combinations of markups.  Instead
we defined them as combinations of stencils.  Stencils are graphical objects
that are formatted for output, and they are wrapped inside of markups to
provide an interface to .ly code.  (This explanation is probably not perfect
technically, but it works for me).

I think if you used scheme code to combine stencils (rather than using the
markup combination commands), you could avoid the def-macro part.  I'm not
saying you *need* to do this, but if it were me I'd at least try it.

> 
> This defines both music command and markup command (more important at a
> later stage when the music command will simultaneously change the
> midiRegisterInstrument of the Voice or something while the markup
> command does just markup).
> 
> Ok, any advice how to wedge material into new Voice context properties?
> How to do that?

I'm not sure what you mean.  What material do you want to wedge into Voice
context properties?

It seems to me like you could define a music function that would:

A) Check the current midiInstrument; if it's not the one you want, change
the midiInstrument.

B) Call the appropriate markup function

c) Send the appropriate notes to the midi performer (which, IIUC, may not be
the notes that are notated on the staff).

Is there something else that needs to be wedged into Voice context
properties?

HTH,

Carl





reply via email to

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