On 10/08/2009 10:52, John Mandereau wrote:
Le lundi 10 août 2009 à 00:36 +0100, Ian Hulin a écrit :
So providing we could stitch this into the lilypond parsing, you could get
\afterGrace #(5.16) {c'1} {d16[ e16]) ;or
\afterGrace {c1} {d16[ e16]} ; or even
\afterGrace #:fraction #(5.16} #ma
Le lundi 10 août 2009 à 00:36 +0100, Ian Hulin a écrit :
> So providing we could stitch this into the lilypond parsing, you could get
> \afterGrace #(5.16) {c'1} {d16[ e16]) ;or
> \afterGrace {c1} {d16[ e16]} ; or even
>
> \afterGrace #:fraction #(5.16} #main: {c1} #grace {d16[ e 16]} ; and
> \af
On 10/08/2009 09:03, John Mandereau wrote:
Le dimanche 09 août 2009 à 16:43 -0600, Carl Sorensen a écrit :
How about \afterGraceSpacing?
That's OK for me; unless there is any objection on the command name,
I'll add the function with this name.
Best,
John
I still think it's
Le dimanche 09 août 2009 à 16:43 -0600, Carl Sorensen a écrit :
> How about \afterGraceSpacing ?
That's OK for me; unless there is any objection on the command name,
I'll add the function with this name.
Best,
John
signature.asc
Description: Ceci est une partie de message numériquement signée
On 09/08/2009 23:23, John Mandereau wrote:
Sorry for my initial reply to this, it was not enough to the point, I'm
trying again :-)
Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
Well, now I think we're pretty much back at Han-Wen's original
suggestion, which was to have two comman
Carl Sorensen wrote:
> Hmmm... The planned syntax improvements are to get rid of prefix commands,
> but music functions are always prefix operators. So I guess we'll be
> distinguishing between "commands" (or some other name -- operators?) and
> music functions.
>
> We will need to be careful
On 8/9/09 4:23 PM, "John Mandereau" wrote:
> Sorry for my initial reply to this, it was not enough to the point, I'm
> trying again :-)
>
> Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
>> Well, now I think we're pretty much back at Han-Wen's original
>> suggestion, which was to
Sorry for my initial reply to this, it was not enough to the point, I'm
trying again :-)
Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
> Well, now I think we're pretty much back at Han-Wen's original
> suggestion, which was to have two commands, one for temporary
> afterGraceFractio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Freitag, 7. August 2009 07:52:53 schrieb Werner LEMBERG:
> > It's only for some exotic tweaks that you might want to change the
> > fraction to something else than the default 15/16...
>
> Hmm. Section 1.2.6 in notation.pdf says that 3/4 is the def
Werner LEMBERG wrote:
> > It's only for some exotic tweaks that you might want to change
> > the fraction to something else than the default 15/16...
>
> Hmm. Section 1.2.6 in notation.pdf says that 3/4 is the default
> value for \afterGrace. A documentation bug?
Nope. Honest mistake.
- Mark
> It's only for some exotic tweaks that you might want to change the
> fraction to something else than the default 15/16...
Hmm. Section 1.2.6 in notation.pdf says that 3/4 is the default value
for \afterGrace. A documentation bug?
Werner
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 6. August 2009 19:39:22 schrieb John Mandereau:
> Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
> > \afterGrace
> > \afterGraceCustom
> >
> > Though I admit, I'm not particularly fond of this solution.
>
> Neither
2009/8/6 John Mandereau :
>> \afterGrace {d1 {c16[ d] }} % works as now - except extra braces
>> \afterGrace {d1 {c16[ d] } 15 16} % extra two optional parameter does
>> the biz currently done by
>
> Music functions are defined in a simpler way: they take a fixed number
> of arguments, and by conv
Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
> \afterGrace
> \afterGraceCustom
>
> Though I admit, I'm not particularly fond of this solution.
Neither am I. Why not just junk the form?
> This would require modifying the define-music-function defmacro
> (on line 764 of
Ian Hulin wrote:
> Is there a way of do this sort of thing sometime in the future?
>
> \afterGrace {d1 {c16[ d] }} % works as now - except extra braces
> \afterGrace {d1 {c16[ d] } 15 16} % extra optional parameters
Well, now I think we're pretty much back at Han-Wen's original
suggestion, which
Le jeudi 06 août 2009 à 16:14 +0100, Ian Hulin a écrit :
> At the moment it looks like we're setting the equivalent of a global
> static variable to do this - bad news for such a specific function.
Indeed.
> Is there a way of do this sort of thing sometime in the future?
>
> \afterGrace {d1 {
Han-Wen Nienhuys wrote:
On Thu, Aug 6, 2009 at 11:19 AM, Mark Polesky wrote:
Han-Wen Nienhuys wrote:
I think in general the manual should not encourage users to define or
set variables using Scheme, exactly because the scoping semantics are
confusing.
I just had an idea. Why no
On Thu, Aug 6, 2009 at 11:19 AM, Mark Polesky wrote:
>
> Han-Wen Nienhuys wrote:
>
>> I think in general the manual should not encourage users to define or
>> set variables using Scheme, exactly because the scoping semantics are
>> confusing.
>
> I just had an idea. Why not make afterGraceFraction
Han-Wen Nienhuys wrote:
> I think in general the manual should not encourage users to define or
> set variables using Scheme, exactly because the scoping semantics are
> confusing.
I just had an idea. Why not make afterGraceFraction a context property
for Score? Wouldn't that solve all of these
On Fri, Jul 31, 2009 at 3:10 PM, Mark Polesky wrote:
>
> Han-Wen Nienhuys wrote:
>> No. In the specific case, I'd recommend making another music
>> function that takes an argument, so you can pass the 15/16
>> explicitly, without mucking with variables.
>
> So it sounds like you believe that one w
Mark Polesky wrote:
Han-Wen Nienhuys wrote:
No. In the specific case, I'd recommend making another music
function that takes an argument, so you can pass the 15/16
explicitly, without mucking with variables.
So it sounds like you believe that one way or another, the burden
should be on the
2009/7/31 Patrick McCarty :
> I *think* that's true.
Hmm, what about primitive procedures? I wouldn't class these as
identifiers, but they'll also return #t:
#(display (defined? 'car))
=> #t
Since ly:parser-lookup returns EOL if it can't find the variable, the
following is probably a safer bet
On Fri, Jul 31, 2009 at 2:44 PM, Trevor Daniels wrote:
>
> Mark Polesky wrote Friday, July 31, 2009 8:51 PM
>>
>> I'm okay with it. But I'd like to see what the others think. Am
>> I correct in thinking that if an object returns #t for this test
>> from within a .ly file, it qualifies as a "parser
Mark Polesky wrote Friday, July 31, 2009 8:51 PM
I'm okay with it. But I'd like to see what the others think. Am
I correct in thinking that if an object returns #t for this test
from within a .ly file, it qualifies as a "parser variable"?
#(defined? 'object-name)
Sorry, I don't know. Anyone
Trevor Daniels wrote:
> No, I don't think this is a *common* error.
> I've never seen it mentioned on -user. And
> it's too obscure for the LM anyway.
>
> What we could do is add a full explanation of
> parser (or global) variables in NR 6.8 "Difficult
> tweaks", together with your warning, and
Mark Polesky wrote Friday, July 31, 2009 7:10 PM
Han-Wen Nienhuys wrote:
No. In the specific case, I'd recommend making another music
function that takes an argument, so you can pass the 15/16
explicitly, without mucking with variables.
So it sounds like you believe that one way or another,
Han-Wen Nienhuys wrote:
> No. In the specific case, I'd recommend making another music
> function that takes an argument, so you can pass the 15/16
> explicitly, without mucking with variables.
So it sounds like you believe that one way or another, the burden
should be on the user. Then do you t
On Fri, Jul 31, 2009 at 3:39 AM, Mark Polesky wrote:
>
> \score {
> \relative {
> <<
> %% value of "afterGraceFraction" inherited from previous score.
> { c1 \afterGrace d1 { c16[ d] } c1 }
> #(define afterGraceFraction (cons 15 16))
> { c1 \afterGrace d1 { c16[ d] } c1 }
> >>
>
Han-Wen Nienhuys wrote:
> Braces are overloaded in LilyPond. In some cases they define scopes
> (like \paper and \header), and in other cases, they just group
> syntactic constructs (\book, \score, sequential musics).
>
> The solution you propose sounds hairy to me. I think you probably
> are l
On Thu, Jul 30, 2009 at 7:19 PM, Mark Polesky wrote:
> The problem with this approach is that if one uses "define" (or
> preferably "set!" as Neil mentioned) to change the variable within a
> music block, the new value persists beyond the closing curly-brace of
> the music block. It will even persi
>> What about resetting all such variables automatically at the
>> beginning of a new \score block?
>
> Awesome! How?
No idea! :-)
Han-Wen?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilyp
Werner LEMBERG wrote:
> I don't like this very much. It effectively doubles the number
> of variables to be known by the user, even if the name can be
> algorithmically derived.
>
> What about resetting all such variables automatically at the
> beginning of a new \score block?
Awesome! How?
-
> I experimented a little bit with one possible solution, but I don't
> know how practical the rest of you will find it. For each parser
> variable, it is possible to define a separate "default" value. The
> existing variable would be initialized to the default value, and it
> would be reset to
I remember being confused and frustrated about this long ago. Now I've
hit upon it again. Parser variables -- I don't know if this is the
official term, but it's what Neil used to describe variables that are
accessible with ly:parser-lookup. He gave the example of
afterGraceFraction, which can be
34 matches
Mail list logo
