Re: music function semantics
W dniu 31 lipca 2011 01:23 użytkownik James Lowe james.l...@datacore.com napisał: Then what would be the purpose of \once \override; or is that your point? Yeah, making \once \override work like \tweak is my point. But i'm not sure about it, it's just an idea for GLISS. W dniu 31 lipca 2011 01:48 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 7/30/11 4:37 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does I guess we'll have this out in GLISS. But I think it would be a major inconvenience. If I want to have the all the notes at the current instant made red, I can do it with a single call to \once \override. If we make \once \override work like \tweak, I'd need a call for each note head. Definately it's a topic for GLISS. 2011/7/31 David Kastrup d...@gnu.org: Carl Sorensen c_soren...@byu.edu writes: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, you need to do \tweak ... c Yeah... While i can learn to live with that (albeit very painfully), there are plenty of people whose minds would simply blow because of this (you know, ordinary people without geek-skills). I have some more to say about this, but i guess it will be best suited when we discuss GOP-PROP roadmap of future development. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Am Sunday, 31. July 2011, 01:48:16 schrieb Carl Sorensen: On 7/30/11 4:37 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does It would be. With the current \once\override you can also change all object in the whole score. With a tweak you have to change each and every voice separately. I guess we'll have this out in GLISS. But I think it would be a major inconvenience. If I want to have the all the notes at the current instant made red, I can do it with a single call to \once \override. If we make \once \override work like \tweak, I'd need a call for each note head. Yes, I'd argue strongly against removing \once\override. 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Am Sunday, 31. July 2011, 01:56:02 schrieb David Kastrup: Carl Sorensen c_soren...@byu.edu writes: The principles: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, It works on the whole chord, unfortunately (similar to how \harmonic and fingering do only work within a chord). In other words, it's equivalent to \tweak c 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Sunday, 31. July 2011, 01:56:02 schrieb David Kastrup: Carl Sorensen c_soren...@byu.edu writes: The principles: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, It works on the whole chord, unfortunately (similar to how \harmonic and fingering do only work within a chord). In other words, it's equivalent to \tweak c Like with the hierarchy of contexts that makes it a mess to figure out just where and when to set a property, the tweak should percolate to where it makes sense. Personally, I'd consider it more predictable if c did not create a chord, but it would likely make a mess of existing music functions and their application designed by reverse engineering. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
2011/7/29 David Kastrup d...@gnu.org: Jan Warchoł lemniskata.bernoulli...@gmail.com writes: if i understood you correctly (it's about the difference in syntax between tweak and override?), i agree that it's quite a serious problem. There is not all that much, really. Take a look at music-functions.scm, for example style-note-heads. It's sort of polymorphic since it can be called in various places. It looks at the type of received music expression in order to figure out where it was called, and does a tweak or an override depending on what will work in that context. I see... The more i think about it, the more i feel it would be good to merge \set, \override and \tweak into one thingy. Doing so would make music functions like above one quite simpler. GLISS - i can't wait for you! cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
On 7/30/11 9:33 AM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I see... The more i think about it, the more i feel it would be good to merge \set, \override and \tweak into one thingy. Doing so would make music functions like above one quite simpler. While I could see that perhaps we could combine \set and \override, we cannot combine \tweak. \override and \set modify everything at the current moment. \tweak modifies only a single grob. The distinction between \override and \tweak needs to stay because it is a semantic distinction. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Am Samstag, 30. Juli 2011, 18:18:49 schrieb Carl Sorensen: On 7/30/11 9:33 AM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I see... The more i think about it, the more i feel it would be good to merge \set, \override and \tweak into one thingy. Doing so would make music functions like above one quite simpler. While I could see that perhaps we could combine \set and \override, we cannot combine \tweak. \override and \set modify everything at the current moment. Exactly. While \override changes the value of a grob property, \set changes a context property. However, the syntax is sufficiently different (\override needs a [Context.]grob and a property, \set only a [Context.]property) to distinguish them even if we use the same command name. (To be honest, I think David's very first lilypond proposal of merging them to one single command was not so bad after all...) The largest different is that \revert and \unset work completely different. \tweak modifies only a single grob. Yes, and it is meant to be used in places where you can't use \override or \set. Or put differently, \set and \override change the global defaults before things are created, while \tweaks works on one particular graphical object that was already created. The distinction between \override and \tweak needs to stay because it is a semantic distinction. Yes, I fully agree with all your points. 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: music function semantics
Hello,
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of David Kastrup
)Sent: 30 July 2011 17:03
)To: lilypond-devel@gnu.org
)Subject: Re: music function semantics
)
)Jan Warchoł lemniskata.bernoulli...@gmail.com writes:
)
) 2011/7/29 James Lowe james.l...@datacore.com:
)
) 29 July 2011 08:11 Jan Warchol wrote:
) )...ah, so it is possible to modify ties in a chord separately! Do
) you realize )that i didn't know about it?
)
) Snippet for LSR?
)
) I tried to write it, and do you know what? It doesn't work! Very stupid.
)
) % if you apply this tweak to first note (c'), it works (tie gets
) weird). However, when applied to second note, it doesn't.
) { c' ~ g'-\tweak #'control-points #'((1 . -1) (3 . 0.6) (12.5 .
) 0.6) (14.5 . -1)) ~q }
)
)If you take a look at the output of
)
)\displayMusic { c'-\tweak #'control-points #'((1 . -1) (3 . 0.6) (12.5 .
)0.6) (14.5 . -1)) ~ g'-\tweak #'control-points #'((1 . -1) (3 . 0.6) (12.5 .
)0.6) (14.5 . -1)) ~q }
)
)you'll see that it is not the fault of the parser. The music expression still
)carries the respective information.
)
This is a bit too low level for me now.
So is this a bug or something else? (I.e do we need a tracker item or not?) and
can we tie individual notes within in a chord or not?
?:)
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Am Samstag, 30. Juli 2011, 20:01:36 schrieb James Lowe: This is a bit too low level for me now. Hehe. What David wanted to say: The parser correctly interprets the syntax and properly sets the control-points for the TieEvent. So, his part of current interest (the parser) works just fine. However, there might be a bug later on when the graphical tie object is actually created from the music expression. There, the control-points seem to be handled differently for the two notes, even though both ties have the same value assigned... So is this a bug or something else? (I.e do we need a tracker item or not?) and can we tie individual notes within in a chord or not? Yes, we can tie individual notes within a chord. c~ e g~4 c e g c It's just the tweak that seems to be broken in your case... I would say this is a bug, although of low priority. 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
W dniu 30 lipca 2011 18:18 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 7/30/11 9:33 AM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I see... The more i think about it, the more i feel it would be good to merge \set, \override and \tweak into one thingy. Doing so would make music functions like above one quite simpler. While I could see that perhaps we could combine \set and \override, we cannot combine \tweak. \override and \set modify everything at the current moment. \tweak modifies only a single grob. The distinction between \override and \tweak needs to stay because it is a semantic distinction. Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does. The reason i'm so concerned about it is because today i managed to do unbelieveable amount of mistakes when trying to move a markup. I've forgotten about the hash, the quote and the dash (in different combinations) before i finally wrote -\tweak #'X-offset #3 . At some moment i even thought it cannot be done like that. A shame - only i'm not sure who should be ashamed more, me or Lily :P cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: music function semantics
Hello, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Jan Warchoł [lemniskata.bernoulli...@gmail.com] Sent: 30 July 2011 23:37 To: Carl Sorensen Cc: David Kastrup; lilypond-devel@gnu.org Subject: Re: music function semantics W dniu 30 lipca 2011 18:18 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 7/30/11 9:33 AM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I see... The more i think about it, the more i feel it would be good to merge \set, \override and \tweak into one thingy. Doing so would make music functions like above one quite simpler. While I could see that perhaps we could combine \set and \override, we cannot combine \tweak. \override and \set modify everything at the current moment. \tweak modifies only a single grob. The distinction between \override and \tweak needs to stay because it is a semantic distinction. Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does. - Then what would be the purpose of \once \override; or is that your point? I'm not sure that stopping \once \override from affecting all objects at the same moment is a good thing. I cannot think of anything immediately, but surely \once \override is better than lots of \tweaks - it would certainly make the LP code more legible. Just my tuppence worth. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
On 7/30/11 4:37 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote:
W dniu 30 lipca 2011 18:18 użytkownik Carl Sorensen
c_soren...@byu.edu napisał:
On 7/30/11 9:33 AM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote:
I see...
The more i think about it, the more i feel it would be good to merge
\set, \override and \tweak into one thingy. Doing so would make music
functions like above one quite simpler.
While I could see that perhaps we could combine \set and \override, we
cannot combine \tweak.
\override and \set modify everything at the current moment.
\tweak modifies only a single grob.
The distinction between \override and \tweak needs to stay because it is a
semantic distinction.
Hmm, i'd say that \once \override could work like tweak. Currently
\once \override affects all objects created at the same moment in
given context, but i think it wouldn't be of much inconvenience if it
affected only a single object, like tweak does
I guess we'll have this out in GLISS. But I think it would be a major
inconvenience. If I want to have the all the notes at the current instant
made red, I can do it with a single call to \once \override. If we make
\once \override work like \tweak, I'd need a call for each note head.
The reason i'm so concerned about it is because today i managed to do
unbelieveable amount of mistakes when trying to move a markup. I've
forgotten about the hash, the quote and the dash (in different
combinations) before i finally wrote -\tweak #'X-offset #3 . At some
moment i even thought it cannot be done like that.
A shame - only i'm not sure who should be ashamed more, me or Lily :P
The principles:
\tweak comes immediately before the object to be modified.
Any scheme value needs to be introduced with #
All properties are scheme identifiers, so they need a quote before them.
so
- \tweak #'X-offset #3 \markup {foo}
is what you need.
I don't think we'll have much change to this in GLISS, but I might be
wrong
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Carl Sorensen c_soren...@byu.edu writes: The principles: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, you need to do \tweak ... c instead. I have half a mind to change isolated notes not to use chords (which would likely fix that problem), but am afraid that this will break gazillions of music functions designed with reverse engineering, like suggested in the manual. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
On 7/30/11 5:56 PM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: The principles: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, you need to do \tweak ... c \tweak still comes immediately before the object to be modified. It just can't modify a single note. Thanks, Carl instead. I have half a mind to change isolated notes not to use chords (which would likely fix that problem), I think that fix is potentially valuable. I'd like to see how it would work. but am afraid that this will break gazillions of music functions designed with reverse engineering, like suggested in the manual. It might fix some fingering things, though. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
David, 2011/7/27 David Kastrup d...@gnu.org: Neil Puttock n.putt...@gmail.com writes: On 26 July 2011 22:41, David Kastrup d...@gnu.org wrote: So the question basically is: which of those mechanisms is actually being in use? Are there examples for existing music functions interpreting a postevent or a chord constituent? \tweak would be the most common usage for both of these cases: c1-\tweak #'color #red -\fermata and \tweak #'color #red c1 So much for my nobody needs that theory. The problem I have is that accepting \transpose in all the same places as \tweak does not seem like a good idea. On the other hand, whether an error gets thrown by the parser or by the expression builder might not make that much of a difference to the end user than it feels like making to me. if i understood you correctly (it's about the difference in syntax between tweak and override?), i agree that it's quite a serious problem. ...ah, so it is possible to modify ties in a chord separately! Do you realize that i didn't know about it? I'd say that this means the current state of things is too complicated. I vote for changing the way things work completely (GLISS time approaches, after all :P). sorry if this is not very helpful... maybe i'll have specific ideas later. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Jan Warchoł lemniskata.bernoulli...@gmail.com writes: David, 2011/7/27 David Kastrup d...@gnu.org: Neil Puttock n.putt...@gmail.com writes: On 26 July 2011 22:41, David Kastrup d...@gnu.org wrote: So the question basically is: which of those mechanisms is actually being in use? Are there examples for existing music functions interpreting a postevent or a chord constituent? \tweak would be the most common usage for both of these cases: c1-\tweak #'color #red -\fermata and \tweak #'color #red c1 So much for my nobody needs that theory. The problem I have is that accepting \transpose in all the same places as \tweak does not seem like a good idea. On the other hand, whether an error gets thrown by the parser or by the expression builder might not make that much of a difference to the end user than it feels like making to me. if i understood you correctly (it's about the difference in syntax between tweak and override?), i agree that it's quite a serious problem. There is not all that much, really. Take a look at music-functions.scm, for example style-note-heads. It's sort of polymorphic since it can be called in various places. It looks at the type of received music expression in order to figure out where it was called, and does a tweak or an override depending on what will work in that context. ...ah, so it is possible to modify ties in a chord separately! Do you realize that i didn't know about it? I'd say that this means the current state of things is too complicated. The documentation for music functions sucks a lot. Some things are currently done with music functions that you would not guess possible from their documentation (I was surprised that \tweak is a music function, for example, though it acts less intelligent about it than style-note-heads). I vote for changing the way things work completely (GLISS time approaches, after all :P). Documenting the existing way would help a lot already. My patch does that, and it extends the behavior and functionality somewhat, so that the documentation is less embarrassing. sorry if this is not very helpful... maybe i'll have specific ideas later. I am not all too far from committing. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: music function semantics
Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Jan Warchol )Sent: 29 July 2011 08:11 )To: David Kastrup )Cc: lilypond-devel@gnu.org )Subject: Re: music function semantics ) )David, ) )2011/7/27 David Kastrup d...@gnu.org: ) Neil Puttock n.putt...@gmail.com writes: ) ) On 26 July 2011 22:41, David Kastrup d...@gnu.org wrote: ) ) So the question basically is: which of those mechanisms is actually ) being in use? Are there examples for existing music functions ) interpreting a postevent or a chord constituent? ) ) \tweak would be the most common usage for both of these cases: ) ) c1-\tweak #'color #red -\fermata ) ) and ) ) \tweak #'color #red c1 ) ) So much for my nobody needs that theory. The problem I have is that ) accepting \transpose in all the same places as \tweak does not seem ) like a good idea. ) ) On the other hand, whether an error gets thrown by the parser or by ) the expression builder might not make that much of a difference to the ) end user than it feels like making to me. ) )if i understood you correctly (it's about the difference in syntax between )tweak and override?), i agree that it's quite a serious problem. )...ah, so it is possible to modify ties in a chord separately! Do you realize )that i didn't know about it? Snippet for LSR? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Neil Puttock n.putt...@gmail.com writes: On 26 July 2011 22:41, David Kastrup d...@gnu.org wrote: So the question basically is: which of those mechanisms is actually being in use? Are there examples for existing music functions interpreting a postevent or a chord constituent? \tweak would be the most common usage for both of these cases: c1-\tweak #'color #red -\fermata and \tweak #'color #red c1 So much for my nobody needs that theory. The problem I have is that accepting \transpose in all the same places as \tweak does not seem like a good idea. On the other hand, whether an error gets thrown by the parser or by the expression builder might not make that much of a difference to the end user than it feels like making to me. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
music function semantics
Hi, I am currently stuck in rethinking what music functions should be able to do. Actually, the point is more that I am _tracing_ that, and the current state is just scary in its inconsistency, which is only alleviated by being pretty much undocumented. So I am not sure which of the undocumented features is actually being used. Currently music functions can occur in three places. Basically standalone as prefix_composite_music, inside of a chord as music_function_chord_body, and as an event modifier as music_function_event. prefix_composite_music may take an arbitrary number of ly:music? arguments, but music_function_chord_body and music_function_event may only have the last argument be a music event, and then music_function_chord_body will get the next chord body event as last argument, and music_function_event will get the following music event attached to the current event. So if we define a music function taking just one music expression as argument, it may end up in any of the three places, getting different music types as argument, and being allowed to return different music types depending on where it is used. Total mess syntactically. If we want to turn something like \transpose into a music function, it is not likely we want to have it accepted in all of those places. And we probably won't care for the error messages we get when it is used on a postevent. So the question basically is: which of those mechanisms is actually being in use? Are there examples for existing music functions interpreting a postevent or a chord constituent? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
On 26 July 2011 22:41, David Kastrup d...@gnu.org wrote: So the question basically is: which of those mechanisms is actually being in use? Are there examples for existing music functions interpreting a postevent or a chord constituent? \tweak would be the most common usage for both of these cases: c1-\tweak #'color #red -\fermata and \tweak #'color #red c1 Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
