Re: separating music and guitar instructions
On 15 September 2010 19:53, Vicente Solsona wrote: > > dear list, > > [...] > > It probably has something to do with the fact that string numbers and > right hand fingers must be put inside a chord, but skips cannot, but > I'm stuck here. This limitation that string numbers, right hand fingers (but fingeringOrientations too!) require to be put inside a chord construct _is_ annoying. I'm sure some devs already tried to struggle with this, I think there should be at least one open issue about this on the tracker (although I couldn't find it, maybe I used bad keywords)... But this limitation is really annoying and *absolutely not user-friendly* (not understandable from a user point of view). Sorry for this nonconstructive post. Cheers, Xavier -- Xavier Scheuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
v.villen...@gmail.com writes: > This commit adds a \dynamic command to the parser, > which allows for straightforward dynamics such as > > sffz = \dynamic sffz An explicit dynamics defining command should likely offer a way to specify the effect on midi as well. Lilypond-notation contains a section "Controlling MIDI dynamics" that also explains how to create a new -\rfz command affecting MIDI volume as well. But frankly: as an extension interface, the presented method seems rather appalling. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
Hi Valentin,
I like the markup command, but I don't see the need for adding another
keyword just to avoid the inconvenience of using a dash before the
command.
What's wrong with the following?
myDynamic =
#(define-music-function (parser location dyn) (markup?)
(make-music 'AbsoluteDynamicEvent
'text (cond
((string? dyn)
(if (string-every char-set:dynamics dyn)
dyn
(markup #:dynamic-string dyn)))
(else dyn
moltoF = -\myDynamic "molto_f"
\relative c' {
c1\moltoF
}
OK, so this isn't as clean a solution (and might confuse users who don't
understand the distinction between parser keywords and music function
identifiers), but it works fine. It's good enough for things like
\tweak and \bendAfter so why make dynamics a special case?
Cheers,
Neil
http://codereview.appspot.com/2220041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
Graham Percival writes: > On Wed, Sep 15, 2010 at 07:29:40PM +0200, David Kastrup wrote: >> v.villen...@gmail.com writes: >> >> > This could not be implemented purely using Scheme, as the >> > only way to pass an argument is by using a music-function, >> > thereby forbidding postfix commands. >> >> Is there a particular reason we would not want to have a way of defining >> postfix commands in Scheme? > > I would absolutely love such a mechanism, and consider it almost a > necessity before serious GLISS work can begin. I have no idea how > it could be done, or even if it is possible, but I would encourage > any investigations into this. Seems rather straightforward. You'd put an appropriate 'syntax property on the music function definition (possibly by allowing a :syntax keyword argument in define-music-function, defaulting to 'SequentialMusic or something else that makes sense), the lexer would check it and return an appropriately different token that would make the parser execute it without finishing the current time step first, using pretty much the same parser for argument lists as normal music functions do. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to customize iterator behavior?
Am Dienstag, 14. September 2010, 04:43:56 schrieben Sie:
> The case for the part-combiner is actually feasible to solve: since
> the part-combine-iterator first processes music to extract ordered
> events (generating a so-called split list), you can disguise your
> instructions as music events (which would be correctly timed into the
> split-list). You could then make the part-combine-iterator interpret
> these events.
Yes, that was my last resort, which I don't particularly like. Mainly, because
those events would be handled completely different from all other events
(which are handled by engravers, while these events would be handled by a
scheme function that is called long before iterators and engravers do their
jobs).
Besides, I'm struggling with the parser, which is very strict in what it
allows.
In particular, the syntax for customizing partcombine should
1) not have any side effect or visual appearance when not used within
\partcombine,
2) can be used either as \partCombineAuto for all future notes or as
\once\partCombineAuto only for the next following note, and
3) should not be attached to a note (i.e. not post-fix notation)
In particular, code like:
mI = \relative c' {
e4 e \once\partcombineApart c2 |
e2 e |
\partcombineApart r2 c |
\partcombineAutomatic c2 e |
}
mII = \relative c' {
c2 c2 |
c2 c |
c c |
a c
}
\score {
\mI
}
\score {
\new Staff \partcombine \mI \mII
}
should work and (1) not combine only the two c2 in the first measure, and (2)
not use solo in the third measure (i.e. starting from the beginning of the
third measure keep everything apart).
Basically, the only thing that the parser allows at that point in the music
would be simple_music_property_def, so I'm then back to using \set, but
process this event already in the determine-split-list function.
Extending part-combine.scm to include this is not too difficult, though, but
as I said, those \set commands are treated completely different from all other
\set commands...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
Am Mittwoch, 15. September 2010, 19:29:40 schrieb David Kastrup: > v.villen...@gmail.com writes: > > This could not be implemented purely using Scheme, as the > > only way to pass an argument is by using a music-function, > > thereby forbidding postfix commands. > > Is there a particular reason we would not want to have a way of defining > postfix commands in Scheme? I don't think so. The main problem is the parser, AFAIK. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
On Wed, Sep 15, 2010 at 07:29:40PM +0200, David Kastrup wrote: > v.villen...@gmail.com writes: > > > This could not be implemented purely using Scheme, as the > > only way to pass an argument is by using a music-function, > > thereby forbidding postfix commands. > > Is there a particular reason we would not want to have a way of defining > postfix commands in Scheme? I would absolutely love such a mechanism, and consider it almost a necessity before serious GLISS work can begin. I have no idea how it could be done, or even if it is possible, but I would encourage any investigations into this. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
v.villen...@gmail.com writes: > This could not be implemented purely using Scheme, as the > only way to pass an argument is by using a music-function, > thereby forbidding postfix commands. Is there a particular reason we would not want to have a way of defining postfix commands in Scheme? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
I like what you're doing here. I have a couple of comments on the
regtests, and one on the definition of the dynamics.
Thanks,
Carl
http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (left):
http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely#oldcode523
Documentation/notation/expressive.itely:523: @lilypond[verbatim,quote]
I don't like eliminating the simple example. Having both the simple and
complex example is much better, in my opinion.
http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely#newcode539
Documentation/notation/expressive.itely:539: Scheme command, that takes
any string or markup object as its argument.
I prefer
"through the scheme function @code{make-dynamic-script}"
http://codereview.appspot.com/2220041/diff/12001/ly/dynamic-scripts-init.ly
File ly/dynamic-scripts-init.ly (right):
http://codereview.appspot.com/2220041/diff/12001/ly/dynamic-scripts-init.ly#newcode17
ly/dynamic-scripts-init.ly:17: % sfz = \dynamic sfz
I view this list as defining the stuff that is acceptable for midi. If
we're going to go this way (and I think it's probably good to go this
way -- I like what you're doing), then we probably ought to put some
kind of check for things that don't make midi sense.
For example, ff, or pfpfpfp. I'm fine to go ahead and print the
dynamics, but there ought to be a warning that says something like
"dynamic cannot be represented in midi". And somewhere, we'll still
need to have this equivalent list for midi-acceptable dynamics.
http://codereview.appspot.com/2220041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
On Wed, Sep 15, 2010 at 4:30 PM, David Kastrup wrote: > You are travelling backwards in time. Please adjust the direction of > your patches accordingly. Oh, indeed. Done. Cheers, V. Villenave. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
v.villen...@gmail.com writes: > http://codereview.appspot.com/2220041/ You are travelling backwards in time. Please adjust the direction of your patches accordingly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
wrote Wednesday, September 15, 2010 3:05 PM [snip the meat] This breaks the doc build. *cough* make sure that David isn't looking>you idiot I implore you, oh kind and gentle contributor, to check a full build, from scratch, before proposing a large change. I like it! This is even more entertaining! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
On 2010/09/15 14:05:40, Graham Percival wrote:
Initial comments, not a complete review. BTW, these files just say
"upload in
progress". Could you re-upload the patch, maybe after a few fixes?
New patchset uploaded.
I'd write simply
---
Custom centered dynamic marks can be created:
---
I know the old version "talked through the code", but I really don't
think it's
necessary.
Will do.
This is really a code comment rather than docs, but since I'm here
anyway...
Could this be
\dynamic { sfzp }
instead? I get nervous without the {}. This may well require a
different
modification to the parser.
IMHO, \foo { blah } indicates a _mode_, such as markup mode or lyric
mode. This is more like simple commands such as \bar and the like.
I think you mean: @code{}
Yeah. Shit. Yikes
I implore you, oh kind and gentle contributor, to check a full build,
from
scratch, before proposing a large change.
I have, but that was before I updated the docs :)
Cheers,
V.
http://codereview.appspot.com/2220041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
On Wed, Sep 15, 2010 at 3:05 PM, wrote:
> @{make-dynamic-script} handles any markup object as
> I think you mean: @code{}
>
> This breaks the doc build.
Wait, I should clarify -- it breaks plain old "make", since the docs
are processed with makeinfo during a normal "make". I shouldn't have
called that the "doc build", even though it was in a doc file.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
Initial comments, not a complete review. BTW, these files just say
"upload in progress". Could you re-upload the patch, maybe after a few
fixes?
scm/define-markup-commands.scm scm/font.scm
scm/ly-syntax-constructors.scm
http://codereview.appspot.com/2220041/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/2220041/diff/1/Documentation/notation/expressive.itely#newcode483
Documentation/notation/expressive.itely:483: the @code{\dynamic}
command.
I'd write simply
---
Custom centered dynamic marks can be created:
---
I know the old version "talked through the code", but I really don't
think it's necessary.
http://codereview.appspot.com/2220041/diff/1/Documentation/notation/expressive.itely#newcode486
Documentation/notation/expressive.itely:486: sfzp = \dynamic sfzp
This is really a code comment rather than docs, but since I'm here
anyway...
Could this be
\dynamic { sfzp }
instead? I get nervous without the {}. This may well require a
different modification to the parser.
http://codereview.appspot.com/2220041/diff/1/Documentation/notation/expressive.itely#newcode541
Documentation/notation/expressive.itely:541: By default,
@{make-dynamic-script} handles any markup object as
I think you mean: @code{}
This breaks the doc build. *cough* you idiot
I implore you, oh kind and gentle contributor, to check a full build,
from scratch, before proposing a large change.
http://codereview.appspot.com/2220041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Indentation in parser.yy
On Wed, Sep 15, 2010 at 1:06 PM, James wrote:
> On 15/09/2010 12:40, Graham Percival wrote:
>>
>> Good point. Next time I'll do a grumpy&fluffy reply -- first I'll
>> give a Graham-style response to shock&awe, then (in the same
>> email) I'll give a kind and generous response.
>
> and that would be a shame.
...
> I guess we all donate our time for different reasons, but praise and polite
> conversation is not one I do it for.
Hey, moron! All you have to do is stop reading when I tell you to.
There's a reason that the "grumpy" part comes first. Mao, do you
think I'm new to this kind of stuff?
James, Valentin: stop reading. Fluffy bunnies ahead.
I agree that it would be a shame for the community to lose my distinct
style -- I do it deliberately, after all! When properly understood,
they add humour and a "personal touch" to what could otherwise be a
rather boring job (or volunteer effort). The French contributors who
met my stuttering self in Bordeaux can attest that I'm not *at all*
scary in person. :)
OTOH, when read out of context ("context" here meaning the full
multi-year history between me and the people I'm aiming that email
at), some of my emails really do paint a bad picture of our
development community in general, and me in particular.
I think that the "two-pronged" (or "Jekyll and Hyde") approach is the
best way to meet both goals. People who appreciate the nasty can get
their jollies that way, but the very same email will present a fair
and balanced view of the situation.
Wishing you kittens and love,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[Patch] Absolute dynamics as postfix text (issue2220041)
Reviewers: lilypond-devel_gnu.org, Message: Greetings everybody, This is probably not the kind of things anyone wants to see right now, but this feature just seemed really nice to have; I've been aiming to implement it for years. Of course, this surely can wait until the next dev cycle, but since it is a mere drop-in replacement for existing code, it shouldn't (and doesn't AFAIK) break anything. This is my first non-pure-Scheme patch, so please bear with me :) Description: Absolute dynamics as postfix text This commit adds a \dynamic command to the parser, which allows for straightforward dynamics such as sffz = \dynamic sffz or c1 \dynamic "mp,_molto intenso" etc. This could not be implemented purely using Scheme, as the only way to pass an argument is by using a music-function, thereby forbidding postfix commands. The upside with this parser modification is that it acts as a drop-in replacement for the way absolute-dynamic-events were previously handled. make-dynamic-script has been updated accordingly, as well as the documentation and the regtests (the only thing left to implement is a suitable display-method). \dynamic is also used as a markup command, but since the new command lives in a different scope there is no conflict AFAICS. A new dynamic-string markup command has also been added, in order to parse the string argument given to \dynamic. This command accepts plain dynamics as well as text indications and composite indications mixing dynamics, text and punctuation. Please review this at http://codereview.appspot.com/2220041/ Affected files: M Documentation/notation/expressive.itely A input/regression/dynamics-text-postfix.ly M lily/lily-lexer.cc M lily/parser.yy M ly/dynamic-scripts-init.ly scm/define-markup-commands.scm scm/font.scm scm/ly-syntax-constructors.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Indentation in parser.yy
James writes: > On 15/09/2010 12:40, Graham Percival wrote: >> On Wed, Sep 15, 2010 at 08:39:26AM +0200, David Kastrup wrote: >>> Valentin Villenave writes: >>> On Tue, Sep 14, 2010 at 6:11 PM, Graham Percival wrote: > On Tue, Sep 14, 2010 at 4:27 PM, Trevor Daniels > wrote: >> You know, after rebuffs like this it's hardly >> surprising you don't get many people offering to >> help you. > > Valentin is a personal friend, Whilst I do understand that such tactless rebuttals might look impressive and unappealing to newcomers, >>> >>> Doesn't help. Social standards are not something a witness can switch >>> off at will rationally. > > Hmm... 'Pot' and 'Kettle' are two words that spring to mind here David > ;) My personal style does not significantly deteriorate further with familiarity. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: equivalent to \once within scheme?
On 9/15/10 2:09 AM, "Marc Hohl" wrote: > Hello all, > > IIUC, \override grob #'foo = #bar > is more or less the same as > (ly:grob-set-property! grob foo bar) Actually, this is closer to being the equivalent of \tweak. \override context.grob #'foo = #bar is accomplished in scheme with (ly:context-pushpop-property context grob 'foo bar) > > Is there a scheme equivalent for > > \once \override Grob #'foo = #bar ? But I don't know how to do the \once \override in scheme. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Indentation in parser.yy
On 15/09/2010 12:40, Graham Percival wrote: On Wed, Sep 15, 2010 at 08:39:26AM +0200, David Kastrup wrote: Valentin Villenave writes: On Tue, Sep 14, 2010 at 6:11 PM, Graham Percival wrote: On Tue, Sep 14, 2010 at 4:27 PM, Trevor Daniels wrote: You know, after rebuffs like this it's hardly surprising you don't get many people offering to help you. Valentin is a personal friend, Whilst I do understand that such tactless rebuttals might look impressive and unappealing to newcomers, Doesn't help. Social standards are not something a witness can switch off at will rationally. Hmm... 'Pot' and 'Kettle' are two words that spring to mind here David ;) Good point. Next time I'll do a grumpy&fluffy reply -- first I'll give a Graham-style response to shock&awe, then (in the same email) I'll give a kind and generous response. and that would be a shame. I am sure I am not the only person who sees a huge unread thread with certain developers too-ing and fro-ing on it and think "oo goody!", then go make a cup of tea, get some biscuits and settle down for some entertaining 'banter' (even if most of it I can barely follow - the detail is beside the point in most cases). This self-deprecating, second para of this thread kept me amused for days: http://article.gmane.org/gmane.comp.gnu.lilypond.devel/29578 On a slightly less frivolous note, Graham's 'grumpiness' does certainly make me think 'twice' (and sweat slightly) before submitting any patch for LilyPond doc and I am sure it is this grumpiness that has kept the beast that is Doc, in check. Manners doth maketh the man, but it sure has hell wouldn't make good Documentation. I guess we all donate our time for different reasons, but praise and polite conversation is not one I do it for. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Indentation in parser.yy
On Wed, Sep 15, 2010 at 08:39:26AM +0200, David Kastrup wrote: > Valentin Villenave writes: > > > On Tue, Sep 14, 2010 at 6:11 PM, Graham Percival > > wrote: > >> On Tue, Sep 14, 2010 at 4:27 PM, Trevor Daniels > >> wrote: > >>> You know, after rebuffs like this it's hardly > >>> surprising you don't get many people offering to > >>> help you. > >> > >> Valentin is a personal friend, > > > > Whilst I do understand that such tactless rebuttals might look > > impressive and unappealing to newcomers, > > Doesn't help. Social standards are not something a witness can switch > off at will rationally. Good point. Next time I'll do a grumpy&fluffy reply -- first I'll give a Graham-style response to shock&awe, then (in the same email) I'll give a kind and generous response. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Indentation in parser.yy
Valentin Villenave wrote Wednesday, September 15, 2010 12:42 AM On Tue, Sep 14, 2010 at 6:11 PM, Graham Percival wrote: On Tue, Sep 14, 2010 at 4:27 PM, Trevor Daniels wrote: You know, after rebuffs like this it's hardly surprising you don't get many people offering to help you. Seeing this, anyone thinking of offering will likely think again. Valentin is a personal friend, and the grumpy/fluffy interplay has been a constant between us. I take much more liberties with him than I would anybody else. Yes, I know that, and I know Valentin's coefficient of restitution is amazingly high! But some of us are more brittle, and don't (immediately) bounce back. You just need to be reminded of that from time to time :) Whilst I do understand that such tactless rebuttals might look impressive and unappealing to newcomers That was my point. Long-standing members of -devel enjoy the lively interchange, but newcomers don't know the background. But after this exchange they do, so please bicker on :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: equivalent to \once within scheme?
On 2010-09-15 10:24, David Kastrup wrote: Alexander Kobel writes: if _I_ understand correctly, the (ly:grob-set-property! grob ...) is _exactly_ the \once \override ..., since it applies to the specific instance of a grob you give as an parameter. That would rather be a \tweak, wouldn't it? \once \override affects every grob at a given timestep. D'oh. Of course. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: equivalent to \once within scheme?
Alexander Kobel schrieb: On 2010-09-15 10:09, Marc Hohl wrote: Hello all, IIUC, \override grob #'foo = #bar is more or less the same as (ly:grob-set-property! grob foo bar) Is there a scheme equivalent for \once \override Grob #'foo = #bar ? Hi, Marc, if _I_ understand correctly, the (ly:grob-set-property! grob ...) is _exactly_ the \once \override ..., since it applies to the specific instance of a grob you give as an parameter. It just depends where you call it - which is usually inside some callback set by \override Grob #'after-line-breaking or such. Thus, the (ly:grob-set-property grob ...) is called for every grob of type Grob. But if you, say, construct grobs in scheme, and run the function only for one of the resulting grobs, or apply it only the second instance of a broken spanner (which is divided into two grobs (or even more for a three-system-long VoltaBracket, e.g.?) it behaves exactly like a \once \override. Hi Alexander, thanks for your quick response and the explanation! Marc HTH, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: equivalent to \once within scheme?
Alexander Kobel writes: > On 2010-09-15 10:09, Marc Hohl wrote: >> Hello all, >> >> IIUC, \override grob #'foo = #bar >> is more or less the same as >> (ly:grob-set-property! grob foo bar) >> >> Is there a scheme equivalent for >> \once \override Grob #'foo = #bar ? > > Hi, Marc, > > if _I_ understand correctly, the (ly:grob-set-property! grob ...) is > _exactly_ the \once \override ..., since it applies to the specific > instance of a grob you give as an parameter. That would rather be a \tweak, wouldn't it? \once \override affects every grob at a given timestep. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: equivalent to \once within scheme?
On 2010-09-15 10:09, Marc Hohl wrote: Hello all, IIUC, \override grob #'foo = #bar is more or less the same as (ly:grob-set-property! grob foo bar) Is there a scheme equivalent for \once \override Grob #'foo = #bar ? Hi, Marc, if _I_ understand correctly, the (ly:grob-set-property! grob ...) is _exactly_ the \once \override ..., since it applies to the specific instance of a grob you give as an parameter. It just depends where you call it - which is usually inside some callback set by \override Grob #'after-line-breaking or such. Thus, the (ly:grob-set-property grob ...) is called for every grob of type Grob. But if you, say, construct grobs in scheme, and run the function only for one of the resulting grobs, or apply it only the second instance of a broken spanner (which is divided into two grobs (or even more for a three-system-long VoltaBracket, e.g.?) it behaves exactly like a \once \override. HTH, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Accidentals algorithm
I made an algorithm that computes accidentals on the algebraic level: the notes of the scales of staff and music are defined by linear combinations from a set of formal seconds. The typesetting is independent of the tuning system: the pitches are found by plugging values into these seconds, which can be done when writing an audio file. There is another algorithm for doing that. The idea is to allow for very general types of scales and music. The staff scale does not need to be the traditional minor scale, have seven notes per diapason, or even defined by just a minor and a major second. There Haskell code is available, in case somebody wants to check if it might be useful for LilyPond. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
equivalent to \once within scheme?
Hello all, IIUC, \override grob #'foo = #bar is more or less the same as (ly:grob-set-property! grob foo bar) Is there a scheme equivalent for \once \override Grob #'foo = #bar ? Thanks in advance! Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
