lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some engraver brainstorming


From: Marc Hohl
Subject: Re: Some engraver brainstorming
Date: Sat, 08 May 2010 10:43:31 +0200
User-agent: Thunderbird 2.0.0.24 (X11/20100317)

David Kastrup schrieb:
[...]

So how about the ultimate tweak: using a separate engraver?  We can't
have overlapping slurs with a single engraver, for example.  But if we
write something like

<c( address@hidden( g> <address@hidden) f)>

and use @1 with the scope of a tweak, and let it use the engraver of
subvoice 1 (a subvoice having its own engraver copies that get to handle
basic events just from its own subvoice), then it becomes possible to
use parallel slurs in one voice.
A similar problem arised with the (not yet finished - to be honest: not really started) implementation of string bends. Here, we want use the string indicator as separation
number.

I think I like your idea to give musical elements a distinct number (or even a more
general mark) which can later be referred to.

How would you then code your glissando example?

<address@hidden address@hidden e> <address@hidden address@hidden f>

[...]
Of course, all this tastes of "goto" in that it would be a nightmare to
translate into MusicXML and its ilk.  But the \hideNotes in separate
Voice construct works just by chance (as long as the hidden constructs
are similar enough to have exactly the same spacing) and also is not
nice to put into MusicXML.  And a pain to document in snippets.
The hidden voice constructs just work properly in standard situations
and need a lot of heavy tweaking in most cases. For example, if I
set StringNumber #'transparent = ##t to remove the string indications,
because I have a tablature which shows the string positions anyway,
I don't want to do this again and again in every on-the-fly created
subvoice. So the instantiated subvoices should take care of the settings
of the context they are called in, but still should be tweakable, of course.
And make no mistake: something like this is _needed_ all the time.
+1

Marc





reply via email to

[Prev in Thread] Current Thread [Next in Thread]