Copying to the list, from an off-list conversation.
Which I started since I wasn't sure I was saying anything useful.
On Sat, May 14, 2016 at 2:13 PM, Gianmaria Lari <gianmarial...@gmail.com>
wrote:

> Ciao David, you wrote:
>
> > Great news!  I'll have to look into that since I'm not familiar with
> > groupTag.
>
> If you want to check how I fixed the issue with groupTag here they are
> a complete example. I attached the following files:
>
> - Basile - bambinette.ly: the music file
> - AccordionStandardBass.ly: the library I wrote (and you've already
> seen) adding accordion standard bass facilities
> - AddStaccato.ly: a function to add some articulation to a music expression
> - SetNotesDuration.ly: a function to change the duration if a music
> expression
>
> You should be able to compile all the code. Let me know if you've any
> problem.
> If you check this new version of AccordionStandardBass.ly you will see
> there is just a new line at the beginning of the file
>
> \tagGroup #'(screenOut midiOut)
>
> This is enough to fix all the issues :)
>
> > Since you have this solved to your satisfaction, I only really have a few
> > general comments.
> >
> > The code in your library file is about 10X longer than simply writing out
> > the music in the first place.
> > My approach would be to just do something like this (note that you don't
> > need to use #' any more when specifying tags):
> >
> > cbar = {
> >     \tag screenOut {
> >         c4 c'\majorChordLetter 4 4
> >     }
> >     \tag midiOut {
> >         <c c'>4 <c' e g> 4 4
> >     }
> > }
>
> Yes, there is no advantage or small advantages in using this library
> just to write one (short) music score like that one I included. If I
> intend just to write a single piece of accordion music is better to
> avoid programming and use LP to write music.
>
> But generally at the moment you start recognize pattern of similar
> problem that you need to solve frequently it become interesting
> developing/adapting/extending the language you're using. The goal is
> having new structure to be able to simplify writing, be more synthetic
> and trough higher level functionality write neater script. I imagine
> you know all these.
>

I think the trick here is making sure you make good choices about what to
generalize.

I often find that if I get too happy trying to reuse code.  Then when I
need to make changes that are specific to an instrument, or a particular
iteration, I need to unwind the work I did.


> > What if, for example, you decide to add dynamics or articulations down
> the
> > road?  Where will you enter them?  At rootNoteExp?  Will you have then
> > several versions of rootNoteExp for different dynamics and articulations,
> > and then versions for all the intermediate variables?
>
> This specific problem has been solved using AddStaccato (that I
> attached to this email).
> I wanted this solution and I'm happy it exists! And I see no reason
> why we should not want to have the same for other articulation,
> dynamics etc.
>


> > My point is that, the further you get from using direct musical input
> > syntax, the more difficult it is to add these other elements that may
> vary
> > from instance to instance.
>
> Yes, in case of LP I think you're right. But I reached a good
> compromise with my small library. Now I can easily and neatly write
> accordion with Standard bass notation. At the moment for this specific
> class of problem it is a very nice facility.
>
> > If you've defined everything by a cascade of variables, you basically
> have
> > to start from scratch whenever you have a new variation of elements.
> With
> > the more literal approach I suggest, you just copy & paste to the
> variable
> > definition to one with the modification.
> >
> > cbarP = {
> >     \tag screenOut {
> >         c4\p c'\majorChordLetter 4 4
> >     }
> >     \tag midiOut {
> >         <c c'>4\p <c' e g> 4
> >     }
> > }
>
> Yes I use copy&paste without hesitation each time other approaches does
> not work
>
> > At some point, I think the approach you've started would better
> generalize
> > to using functions.   That way, you don't have to redefine every
> different
> > permutation.
>
> Yes, exactly. And it looks not too hard to implement a functional
> approach to other LP functionalities. So maybe they will be
> standardized in the future, or I will use some snippet like now.
>
>
> > Secondly, there should be no need to replicate everything per pitch.
> Just
> > say:
> >
> > dbar = \transpose c d { \cbar }
>
> You're definitely right!!!! What a mindless man I have been!
>
> I'll make some test and if they work as supposed I will simplify the
> code like you suggest.
>
> Thanks a lot!!!
> Best regards, G.
> P.S. If you want to continue this discussion I suggest continue it on
> the LP mailing list. I think these things can interest other people.



David Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to