On 2013/11/10 11:48:13, janek wrote:
Awesome!!
could you push it in a branch, so that I could read the commits in
sequence?
dev/issue3648
On 2013/11/09 19:05:29, dak wrote:
> You need to use q here. Sorry, but it would not do to turn
>
> << \new Staff { <c e>4 }
> \new RhythmicStaff { 4 4 4 4 }
> >>
>
> into
>
> << \new Staff { <c e>4 }
> \new RhythmicStaff { <c e>4 <c e>4 <c e>4 <c e>4 }
> >>
>
> since then every note stem in RhythmicStaff would have two heads.
The
> main feature is being able to write naked rhythms. In the contexts
> where they are of interest, it should be no problem if they inherit
an
> arbitrary pitch, but they can't magically turn into chords.
Good point.
However, what about restricting the "pitch inheritance" to the
current context,
Like q, expansion is done while scorifying. There are no contexts at
that time. Doing it in the parser (like durations are, and which q
once was) would cause a bloody mess with \relative (which it did with
q). Doing it, say, at iteration, namely _yet_ _another_ time would be
quite a nuisance and it would not be clear just which iterator would
be responsible for keeping state.
or the current music expression (code block inside {} )? I.e. in
\new Staff { <c e>4 4 4 4 }
the pitches would be inherited, while in
<<
\new Staff { <c e>4 }
\new RhythmicStaff { 4 4 4 4 }
>>
And with
pling = #(define-music-function (parser location m) (ly:music?)
#{ $m 8. 16 \times 3/2 { 8 8 8 } #})
then for \pling c'4 the pitch would get inherited, while for
\pling { c'4 } it wouldn't?
We had _all_ of that "restrict to one music expression" discussion in
relation to q. If you feel argumentative, dig out the hundreds of
mails about that feature and reargue them in private. Unless you come
up with something new, I don't see why the conclusion should be
different.
they won't, because LilyPond wouldn't look back further than the
beginning of current context/expression. Do you think that would be
doable?
I am not interested in restarting this discussion.
https://codereview.appspot.com/22120043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
