[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some engraver brainstorming
From: |
David Kastrup |
Subject: |
Re: Some engraver brainstorming |
Date: |
Mon, 10 May 2010 17:07:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
David Kastrup <address@hidden> writes:
> Reinhold Kainhofer <address@hidden> writes:
>
>> Am Samstag, 8. Mai 2010, um 14:28:18 schrieb Werner LEMBERG:
>>> > So how about the ultimate tweak: using a separate engraver? We
>>> > can't have overlapping slurs with a single engraver, for example.
>>
>> Actually, by extending the engraver a little bit it should be
>> possible. I have had that on my list for quite some time...
>
> That's the same for glissandi. But there is not much of a point
> extending every engraver a bit and making its code more complex if the
> same can be done with a more or less universally working approach for
> all spanning engravers.
There are two different issues here to address/kill.
Issue 1 is making spanning engravers (or engravers that can do just one
job between the start and the end of the moment) work for multiple
parallel tasks.
Issue 2 is being able to deal with those parallel life times properly:
letting programmed tasks and user tasks make sure that the intended
instance of an engraver is addressed for a specific task.
Some of the lack of enthusiasm for dealing with issue 1 may be explained
by the necessity of addressing issue 2. For example, we don't have
nested slurs, but then what to make of
<c( d( e(> <d) e) f)>
This particular one does not want to get a solution in terms of nesting,
but likely first in, first out. Unless it doesn't...
So the solution would be to use "selectors". A selector basically just
sets a sorting criterion, and applies to a single "entity". If we apply
it like a \tweak, we'd write:
<c( address@hidden( address@hidden(> <d) address@hidden) address@hidden)>
Syntactically, postfixing might look nicer.
<c( d(@1 e(@2> <d) e)@1 f)@2>
That's assuming @ as a shorthand. Maybe a case for GLISS, though
upwards-compatible. If the syntax is too contentious or the decision
should be postponed, \select 1 might be used, which may at first be the
same as \tweak #'selector #1.
The selector itself would, in input syntax, likely be symbol or number
and be compared with eq? or at most eqv?. That makes it reasonably easy
to create unique selectors programmatically (like the appoggiatura code
creating its own ties internally, currently in conflict with user ties).
A selector basically has the effect of routing the translator interface
to a separate engraver instance (where supported by the engraver,
otherwise it will be ignored). But all without changing the context.
Programmatically, I was intending to do something like a template type
Engraverfactory<GlissandoEngraver> NewGlissandoEngraver;
for definining an Engraver acting on selections. That would make it
quite easy to quickly test the concept on various engravers.
I am not sure that this is the best permanent solution, however, since
it is somewhat lacking in transparency.
--
David Kastrup
- Re: Some engraver brainstorming, (continued)
- Re: Some engraver brainstorming, David Kastrup, 2010/05/09
- Re: Some engraver brainstorming, David Kastrup, 2010/05/08
- Re: Some engraver brainstorming, Francisco Vila, 2010/05/08
- Re: Some engraver brainstorming, Reinhold Kainhofer, 2010/05/08
- Re: Some engraver brainstorming, Carl Sorensen, 2010/05/08
- Re: Some engraver brainstorming, David Kastrup, 2010/05/09
- Re: Some engraver brainstorming,
David Kastrup <=
- Re: Some engraver brainstorming, Carl Sorensen, 2010/05/10
- Re: Some engraver brainstorming, David Kastrup, 2010/05/10
- Re: Following voices in chords?, Graham Percival, 2010/05/07
- Re: Following voices in chords?, Carl Sorensen, 2010/05/07
- Re: Following voices in chords?, David Kastrup, 2010/05/07
Re: Following voices in chords?, Kieren MacMillan, 2010/05/07