than "music-concert-pitch" to me. Although I see in the readme file that
you are rethinking things, so maybe this is a moot point.
Cheers,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Transposing-instruments-in-orchestra-score-tp162176
Hello,
I added a snippet to open-lily-lib:
https://github.com/openlilylib/snippets/tree/master/editorial-tools/auto-transpose
README follows.
Best, Jan-Peter
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/l
Hi again,
I didn't actually tell what the engraver is actually for:
The "autoTranspose"-engraver transposes music automatically, if there
are three context-properties set:
* instrumentTransposition is the pitch, which is set by \transposition
* music-concert-pitch tells whether the music in this c
Hi there,
... now, who's late ;)
I read a few of the messages regarding the given subject. I don't have a
once-and-for-all-solution, but I want bring in another scheme-engraver:
It uses context-properties 'instrumentTransposition, (newly defined)
'music-concert-pitch' and 'print-concert-pitch'.
Hi David,
sounds like a deal. Let me know when you're able to work on it and
maybe also the amount of sponsoring you'll need...
Yours,
Orm
Am Samstag, den 10. Mai 2014 um 15:21:40 Uhr (+0200) schrieb David Kastrup:
>
> I'm thinking about it, but no timeline.
>
> Basically, it requires reworki
Kieren MacMillan writes:
> You have to put the key information redundantly in each instrumentalist’s
> music.
>
> A better [i.e, more maintainable and “object-oriented”] approach is this:
>
> global = {
> \key a \minor s1*8
> \key e \minor s1*4
> \key c \major s1*10
> }
>
> and then in bot
Kieren MacMillan writes:
> Hi all,
>
>> I'd be very willing to sponsor this, if there is a feasible solution
>> within a reasonable amount of time.
>
> I paid Han-Wen to upgrade switchInstrument four or five years ago —
> I’m happy to sponsor more improvements!
I'm thinking about it, but no time
Hi all,
> I'd be very willing to sponsor this, if there is a feasible solution
> within a reasonable amount of time.
I paid Han-Wen to upgrade switchInstrument four or five years ago — I’m happy
to sponsor more improvements!
Best,
Kieren.
—
Kieren MacMillan, composer
www:
Hi List,
glad I'm not the only one with this use case! As I understand the
situation it is a non-trivial matter to get properly implemented.
My offer to sponsor this still holds (especially if it gets done in
the next two months) but it seems no one with the necessary skills
will implement it, s
Hi David,
> I am curious as to what are the "killer" use cases?
I compose and arrange music theatre works (amongst other things). In the pit,
we almost always have a multi-wind player. A very normal part would see that
one person playing:
mm 1-10 on Bb clarinet
mm. 20-42 on [C+8] piccol
in orchestra score (Orm Finnendahl)
>6. Re:Transposing instruments in orchestra score (David Kastrup)
>7. Re:Trill span problem (Simon Albrecht)
>
>
> ----------
>
> Message: 1
> Date: Thu, 8 May 2014 19:18:23 -0400
> From: Kieren MacMillan
> To: David Kastrup
>
Orm Finnendahl writes:
> Hi all,
>
> as I understand the situation, the most convenient situation for all
> would be the possibility of a context switch in mid-score affecting
> the way lilypond is interpreting (seeing) the pitches, which could get
> changed globally by including different files
Hi all,
as I understand the situation, the most convenient situation for all
would be the possibility of a context switch in mid-score affecting
the way lilypond is interpreting (seeing) the pitches, which could get
changed globally by including different files with redefinitions of
the context-s
Kieren MacMillan writes:
> Hello all,
>
> Sorry I’m late to the party…
>
> A critical feature of a proper and useable multi-instrumentalist
> framework would be the ability to put in global variables which
> include the key signature(s) for the work, and the part would present
> the correct trans
Hello all,
Sorry I’m late to the party…
A critical feature of a proper and useable multi-instrumentalist framework
would be the ability to put in global variables which include the key
signature(s) for the work, and the part would present the correct transposition
of that key signature (as wel
Orm Finnendahl writes:
> Hi,
>
> sorry, I seem to have missed the replies to the thread and just reread
> them in the list archive.
>
> David, could you provide me with a hint on how to get the suggested
> masterToScore and masterToPart functions working? I guess this would
> be the most suitabl
Hi,
sorry, I seem to have missed the replies to the thread and just reread
them in the list archive.
David, could you provide me with a hint on how to get the suggested
masterToScore and masterToPart functions working? I guess this would
be the most suitable method for my purpose as I'm generati
Hi David,
thanks, sorry for not noticing this in your previous mail...
--
Orm
Am Donnerstag, den 08. Mai 2014 um 17:50:15 Uhr (+0200) schrieb David Kastrup:
> Orm Finnendahl writes:
>
> > Hi David,
> >
> > below is a minimal example. One of the disadvantages of this notation
> > is obvious,
Orm Finnendahl writes:
> Hi David,
>
> below is a minimal example. One of the disadvantages of this notation
> is obvious, if you render the file: Both parts are in the wrong
> octave. The "\relative c'" has to get moved inside the brackets of the
> \bclarinet and \eb-clarinet calls in order to
Hi David,
below is a minimal example. One of the disadvantages of this notation
is obvious, if you render the file: Both parts are in the wrong
octave. The "\relative c'" has to get moved inside the brackets of the
\bclarinet and \eb-clarinet calls in order to correct this. I'd much
prefer not ha
Saul Tobin writes:
> Naturally, but a music function like that misses the point. The
> current way isn't cumbersome because it's verbose, it's cumbersome
> because it requires breaking music into separate blocks using
> braces. What I'd like to be able to do is change the transposition
> like a c
Naturally, but a music function like that misses the point. The current
way isn't cumbersome because it's verbose, it's cumbersome because it
requires breaking music into separate blocks using braces. What I'd like
to be able to do is change the transposition like a context property, so
that I
Shevek writes:
> If I understand correctly, what Orm wants is to be able to write something
> like this:
>
> clarinet = \relative c' {
> \transposing bf
> c4 d e d |
> \transposing a
> c d e d
> }
>
> And get the output to show d e fs e ef f g f (using English spelling).
> Current
http://lilypond.1069038.n5.nabble.com/Transposing-instruments-in-orchestra-score-tp162085p162144.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Orm Finnendahl writes:
> Hi List,
>
> I'd like to write a part for a transposing instrument in sounding
> pitch, having the score printout in C and the part printout
> transposed. As far as I understand the docs,
Which ones? And which version?
> in this case I'd have to wrap the instrumental
Hi List,
I'd like to write a part for a transposing instrument in sounding
pitch, having the score printout in C and the part printout
transposed. As far as I understand the docs, in this case I'd have to
wrap the instrumental part's music into a "\transpose {}" statement
and not using "\transpos
26 matches
Mail list logo