On Nov 10, 2013 5:11 AM, <d...@gnu.org> wrote:
> 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
