On Sat, Feb 28, 2009 at 10:37 PM, Frédéric Bron wrote:
>
> Because \dim starts on the next note, you have to put it before \ff
> which is the contrary of what happens really! If you put \dim after
> \ff, the "dim" starts on the next note and it is possible that the
> "ff" and the "dim" are not put
> I wrote something like this for my opera, using the 'tweaks acons
> method. I'll see if I can find it back.
Well thank you. I have downloaded your score and found \ind and \nind
but both start on the next note. However, I like the syntax \ind
#"cresc poco a poco". It is a bit more painful than w
On Sun, Mar 01, 2009 at 12:13:52AM +0100, Valentin Villenave wrote:
> how about considering an LSR upgrade now?
I distinctly remember asking you to do this in January,
> Like, before the whole 2.13 bloody mess starts...
Too late for that. I suppose that we *could* backport everything
to stable/
2009/2/22 Graham Percival :
>> Is there a possibility to make \cresc form start on the previous note
>> and not on the next note?
>
> Based on my recollection of the previous two times this was
> discussed on the list (see archives), no.
I wrote something like this for my opera, using the 'tweaks
On 2/28/09 5:37 PM, "Marek Klein" wrote:
>
> My current solution is:
> (set! counter-alist (assoc-set! counter-alist output-suffix (1+
> output-count)))
>
> Reinhold said, it would be better to use ly:parser-define! instead of set!
> But I don't understand how... NR says:
> Function: ly:parser
On 2/28/09 3:43 PM, "John Mandereau" wrote:
> Hi Carl,
> Carl D. Sorensen a écrit :
>> So, just for the record, I guess that the appropriate way to handle this
>> would be to:
>>
>> 1. Search through input/lsr for relevant files.
>> 2. Fix the snippet to make sure it compiles properly.
>> 3
2009/2/28 Carl D. Sorensen
>
> On 2/27/09 11:53 AM, "Reinhold Kainhofer" wrote:
>
> >
> >>> What about set! versus ly:parser-define! ?
> >
> > I would rather use ly:parser-define!, if we can find out why it doesn't
> work.
> > It's simply cleaner than using a global variable...
> >
> >
>
> Marek
2009/2/28 Carl D. Sorensen :
> I've applied the patch, but it did not include modifications to
> input/lsr/demo-midiinstruments.ly.
>
> We can do that once we get the answer about how to properly handle it.
I've just done an LSR update, so it's been amended automatically with
Andrew's new convert
Neil, John, Graham,
how about considering an LSR upgrade now? Like, before the whole 2.13
bloody mess starts...
- How involved would it be?
- Do we have to download the lsr archive, update the whole thing by
ourselves and send the new tarball to Seba?
- How do we update snippets that do not ha
2009/2/28 John Mandereau :
> Hi Carl,
> Carl D. Sorensen a écrit :
>>
>> So, just for the record, I guess that the appropriate way to handle this
>> would be to:
>>
>> 1. Search through input/lsr for relevant files.
>> 2. Fix the snippet to make sure it compiles properly.
>> 3. Copy the snippet
Hi Carl,
Carl D. Sorensen a écrit :
So, just for the record, I guess that the appropriate way to handle this
would be to:
1. Search through input/lsr for relevant files.
2. Fix the snippet to make sure it compiles properly.
3. Copy the snippet to input/new
4. Delete the snippet from input/ls
Graham Percival a écrit :
On Wed, Feb 25, 2009 at 11:18:32AM -, Trevor Daniels wrote:
I think I've muddled through this and updated
input/lsr with my new snippet. As this was
the first time I've used makelsr.py there were
lots of mysterious warnings, but it seems to
have converted and co
James
We discussed this last October, and I agreed to make the change in
2.13, but then the suggestion was made (by Mats):
Better yet, why can't the shorthand automatically "do the right
thing"? i.e.,
<< {} \\ {} >>
should be translated automagically into
<< {} \new Voice {} >>
I'
Joe Neeman wrote:
On Thu, 2009-02-26 at 13:24 +0100, Michael Käppler wrote:
Both fixed. Other comments?
Just one: can you set the environment variables GIT_AUTHOR_NAME and
GIT_AUTHOR_EMAIL so that an actual name and email show up in the patch?
Done.
>From fda64abf3730cbe811e292a17
14 matches
Mail list logo
