be carved out as an independent project.
Another less scientific endeavor but probably with a larger user base
would be accordion support: input language support of
bass/chord/fingering, chord identification, chord typesetting in various
styles (European, American, French).
--
David Kastrup
___
ut that is no longer supported
by either lilypond or convert-ly).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
people well-acquainted with a particular
instrument and/or playing style.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival writes:
> On Fri, Jan 16, 2009 at 12:36:12PM +0100, David Kastrup wrote:
>
>> Obviously, one wants something like that when converting tunes to
>> tabulature. In the course of that, one might also want to be able to
>> insert algorithms for thin
> Can anybody help me figure out how to do this? As far as I can see, it's
> not possible.
Definitely impossible. map returns a list with the same number of
elements as its input. Why do you need to use map in this manner?
--
David Kastrup
get sidetracked to a degree
where the task for which the tool was built got left on the wayside.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
sponsible for the PDFTeX bug reports concerning output files of more
than 2GB size.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
mpressive part is not the absolute size of the PDF file — as you
> note, there are many larger PDFs out there — but the size of the
> *LILYPOND-GENERATED* PDF.
I would not mind having smaller output created. With probably a
thousand elements per page, I am not sure tha
days,
> that the source code has more or less stopped evolving, I can also do
> it manually)
Since git-archive accepts the formats "tar" as well as "zip", it would
seem like a repo server configuration issue (I tried the obvious sf=zip
in the above link, and got an e
t;
<>
\key c \major
<>
<>
<>
<>
\key g \major
<>
<>
<>
<>
\key d \major
<>
<>
<>
<>
\key a \major
<>
<>
<>
<>
\key e \major
<>
<>
<>
<>
\key h \major
<>
<>
<>
<>
\key fis \major
<>
<>
<>
<>
}
The output looks as follows:
<>
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
"Anthony W. Youngman" writes:
> In message <863aeipe74@lola.quinscape.zz>, David Kastrup
> writes
>>
>>Hi,
>>
>>the ambitus engraver seemingly picks the first maximum/minimum in the
>>note sequence and stays with it even when the same ab
orturers.
> ... yeah, sometimes even *I* can't make up stories weirder than
> real life.
You have a room in your underwear? Please no puns about wormholes.
All the best,
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival writes:
> On Mon, Feb 23, 2009 at 03:22:30PM +0100, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Ok, I've just modified the VERSION file with a great fanfare. And
>> > by "great fanfare" I mean sitting in my roo
(shiftamount) here, but -shiftamount since you
already tested the sign.
Also the comment is misleading: x << -2 is _not_ necessarily zero as the
comment proclaims, but rather is unspecified IIRC. It _could_ have
worked by chance and/or the whim o
hordNames { \time 3/4
\partial 4 \mychords }
\new FretBoards { \mychords }
\new Voice { \notes }
\addlyrics { \textlyrics }
>>
}
\score {
\fullscore
}
\score {
\transpose c g { \fullscore }
}
--
David Kastrup
_
ser): #f
ABORT: (wrong-type-arg)
guile>
What gives? What should I rather write here?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
"Carl D. Sorensen" writes:
> On 3/8/09 6:10 AM, "David Kastrup" wrote:
>
>>
>>
>> Hi, I have no idea whether or not the following result is user error or
>> a misfeature. When typesetting the following, in the transposed variant
>>
nstalled tree contains no info files with images.
What point is there in complaining that Linux distributions tend to omit
the images when there is no working Makefile target that would get them
there, and when the instructions that the Makefile gives out don't even
work?
--
David Kastrup
Valentin Villenave writes:
> 2009/3/8 David Kastrup :
>>
>> Hi, using a file debug.ly with the contents
>>
>> #(top-repl)
>>
>> I can get an interactive guile prompt.
>
> Wow, I didn't know you can do that! Where on Earth is such a cool
> feat
me
subdirectory make targets one cannot fathom and/or require running some
other unnoticeable dependencies first.
It might be nice if some developers made it into a habit to try building
from a freshly checked out tree from time to time without reverting to
their secret knowledge.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
John Mandereau writes:
> David Kastrup a écrit :
>> John Mandereau writes:
>>
>>> ..and input/lsr too. I added toplevel info and intall-info target.
>>>
>> No, you didn't.
> Oops, I meant info-install.
I don't think that is
"Carl D. Sorensen" writes:
> On 3/13/09 4:51 AM, "David Kastrup" wrote:
>>
>> It might be nice if some developers made it into a habit to try
>> building from a freshly checked out tree from time to time without
>> reverting to their secret kno
Cameron Horsburgh writes:
> On Fri, Mar 13, 2009 at 12:50:23PM +0100, David Kastrup wrote:
>>
>> make && sudo make install
>
>>
>> does not work.
>
> These work fine for me. They don't make much in the way of
> documentation (which is a g
John Mandereau writes:
> David Kastrup a écrit :
>> I don't think that is standard usage. install-info would be the norm
>> when available.
>>
> Will fix this, but see below my request.
>
>
>>>> make install bombs out, anyway:
>>>>
Han-Wen Nienhuys writes:
> On Fri, Mar 13, 2009 at 8:50 AM, David Kastrup wrote:
>
>> It is a bit disappointing since the info documentation with images is
>> essential for really getting moving smoothly with Lilypond, and the
>> procedure for producing them is so broke
quot; is not a problem, no. It
is just inefficient if everyone with a possible interest of improving
things has to move through the same bottlenecks before starting.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival writes:
> On Fri, Mar 13, 2009 at 12:50:23PM +0100, David Kastrup wrote:
>> Anyway, as it stands, there is no documentation in obvious places about
>> how to make things run, the build procedures are highly non-standard,
>> the targets are non-standard.
>&
John Mandereau writes:
> David Kastrup a écrit :
>> John Mandereau writes:
>>
>>> What does "grep NCSB config.make" (at top of the build tree) does say?
>>>
>>
>> NCSB_SOURCE_FILES = /usr/share/fonts/type1/gsfonts/c059036l.pfb
&
'duration
> (ly:make-duration 2 0 1 1)
> 'pitch
> (ly:make-pitch 0 5 0))
I think that some version of this trick should definitely make it into
the manual, propably in lilypond-internals?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Jan Nieuwenhuizen writes:
> Op zaterdag 14-03-2009 om 15:31 uur [tijdzone +0100], schreef David
> Kastrup:
>
>> If compiling Lilypond from source with default
>> settings means not getting the full docs, this is what all major
>> distributions will distribute
>
>
Han-Wen Nienhuys writes:
> 2009/3/16 David Kastrup :
>
>>> The problems with fixing a build system is that it is a major time
>>> sink without any obvious benefits,
>>
>> Well, one need not replace the innards. However, adapting the names of
>> th
of Lilypond's strengths that it has a better
conceptual grasp of music than, say, MusiXTeX.
So it is a bad sign in my opinion when changes in the input are hard to
consistently make it to MIDI.
Even when one does not want to see MIDI as an output device (an
John Mandereau writes:
> David Kastrup wrote:
>> So it would appear to be a problem that fc-match first finds the true
>> type fonts installed by Canorus, and then this first match is
>> subsequently thrown away by grep -v.
>>
>> So I think you need to figure o
David Kastrup writes:
> John Mandereau writes:
>
>> David Kastrup wrote:
>>> So it would appear to be a problem that fc-match first finds the true
>>> type fonts installed by Canorus, and then this first match is
>>> subsequently thrown away by grep -v.
&g
John Mandereau writes:
> David Kastrup a écrit :
>> Ok, so the bad news: canorus was not in the package repository. So
>> reinstallation is not trivial: I have to dig it up and then install it.
>> And then it is likely that the version I'll be able to find will be
>
David Kastrup writes:
> John Mandereau writes:
>
>> David Kastrup a écrit :
>>> Ok, so the bad news: canorus was not in the package repository. So
>>> reinstallation is not trivial: I have to dig it up and then install it.
>>> And then it is likely that t
David Kastrup writes:
> If one uses the --sort option, one gets dozens of fonts. The Type1 font
> is at the second place and increasingly dissimilar fallbacks follow.
> The fontformat= entry does not seem to change anything any which way.
> Using foundry=urw in contrast help
installed in a preferred
setting?
Namely: do we actually need the URW fonts and nothing else, or do we
need something that the system installation is prepared to call "Century
Schoolbook"?
If for some reason, only the URW version of those fonts is acceptable,
the foundry
. I have no idea
whether newer versions of Debian packagings of Canorus will mangle the
font installation in different ways or install TrueType fonts at all.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
of some of those fonts, system-wide.
The Lilypond configure command finds some of those truetype fonts via
fc-match in preference of the usual Type1 versions coming with
GhostScript. This causes compilation of Lilypond to fail.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
ceptable.
However, Werner made it sound like Lilypond should come with its own
version of the fonts and use that, in which case it would seem sort of
pointless looking for the system-wide installation of those fonts.
So while the above patch fixes the symptom for the particular
configuration with which I encountered the problem, it may be possible
that we are barking up the wrong tree altogether trying to find the
right system font.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
losed development.
With most of the rest, however, the bleeding edge is readily available
as an option, if I am not mistaken.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
orks. I'm a
> musician, not a developer.
I suppose you are mostly playing solo.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
phrase is not to the point. If you insist on being rude
and off-putting (namely a "Complete A-Hole"), you could at least reflect
the essence by paraphrasing this "How to address Complete A-Holes if you
intend to make them do work for you".
--
David Kastrup
___
hile parsing the given
expression (and loads internally some .ily file once with the required
information if necessary, retaining it for further switches).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Francisco Vila writes:
> 2009/5/17 David Kastrup :
>> \notelanguage "english" { ... }
>>
>> which switches the parser to english language while parsing the given
>> expression (and loads internally some .ily file once with the required
>> informa
David Kastrup writes:
> Francisco Vila writes:
>
>> 2009/5/17 David Kastrup :
>>> \notelanguage "english" { ... }
>>>
>>> which switches the parser to english language while parsing the given
>>> expression (and loads internally some .il
uld appear that his approach was foiled by kinks in the current
implementation, and the long-term solution should prefer getting rid of
kinks rather than adding new ones.
Note that I don't have any actual knowledge of the code: it is just that
this conversat
e is no point in offering a half-broken feature and not fix it,
claiming that it was a bad idea in the first place.
So either the external repeat structure feature should be removed or
fixed. Everything else is asking for trouble and problem reports and is
causing the
orchestra, frowns, and says "Forte, messieurs les brass, forte!" They
play again. The conductor waves them off, frowns more, and says "Forte,
I say!". They give everything they can. The conductor stops again,
furious, and hisses "Forte, no
But it avoids stifling the legal situation at some
later point of time.
> However, I am somewhat naive regarding a lot of this.
Copyright and its execution and things like "estoppel" and "dirty hands"
have gone completely bonkers.
for non-Unicode string literals.
I consider this imprudent. At the very least, I don't think it a good
idea to rely on \o to make it through unmolested in all future versions
of Python.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
after considering the signature, so an f flat counts as higher
as an e sharp, never mind that its pitch is lower) and not the pitch
average.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
e.
> Initial clef should be chosen based on overall range,
But today's available clef choice is much smaller. And quite a few
instruments have a fixed clef (which you, if at all, extend using 8va
notation).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
cessary ugliness,
differently when using @nonfrenchspacing. Since the interword space
tears the flow of reading apart worse than the intersentence space, I
consider that a sensible idea.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
cters is 3000, so the extra space comes
into play.
I stand somewhat corrected.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
nt schemes as well that keep track of manual
source line breaks, indentation and comments).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
this limitation, and I think users would
> greatly benefit from having these predefined commands.
This sounds to me like giving users a low-level manual way to fudge
around a bug/design mistake. This sounds like something that should
happen automatically in most cases.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
rule never prints any
naturals" would appear wrong to me.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
nfo AFAICT.
Not trivial, but you could start with a stock texindex source and go
from there. But then that might be quite more versatile than necessary;
likely a much simpler program would work for this, and then one might
actually be able to use a guile script, employing the original sorting
code
Valentin Villenave writes:
> 2009/7/30 David Kastrup :
>> But if the key signature is, say, G major, then a note f would be
>> printed with a natural accidental. So "this rule never prints any
>> naturals" would appear wrong to me.
>
> While the part you q
Mark Polesky writes:
> David Kastrup wrote:
>
>> Huh? The behavior is unlike `dodecaphonic', but that does not make
>> thesecond part right.
>>
>> "this rule never prints accidentals consistent with the key
>> signature"or "
distance lower).
If that is not comprehensible, I can try making a sketch and
photographing it.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
iano), so the current dearth of feedback does not mean that doing
this well was merely an academic exercise.
All the best
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Dot_column_engraver may be better suited in the
> Voice context than in the Staff context.
>
> Thoughts?
Agree.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
collisions result' ? I guess this would
> require significant surgery to the Dot_column_engraver, no?
Likely two engravers, one that does the work per voice, and one that
retries and cleans up if the per-voice engraving sucks.
--
David Kastrup
it
> should be so.
For \bar "", it is probable sensible behavior. For visible bar lines, I
feel hard put to feel the same.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
s been
> enlarged so that it covers the staff vertically.
One has to keep in mind that Metafont does not permit more than 16
different heights per font (something like that, I don't remember the
exact details).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
he possible confusion. With some luck, the warnings
go away as well, but I have not tried this myself and am to lazy to
check the metafont source.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen writes:
> On 8/12/09 11:15 AM, "Michael Käppler" wrote:
>
>> Sorry, that wasn't intended. It was late yesterday and I didn't
>> notice I pressed the wrong button... ;)
>
> Glad I'm not the only one who does this.
Uh oh. Did yo
and is sabotaging the font rendering engine.
If you don't like "jet black", that's something you need to tell your
printer driver, not individual documents.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
ack as an alternative, but RGB black appears like a bad
choice for printing.
Could you specify the details of your "home printer"?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Andrew Hawryluk writes:
> On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote:
>> Andrew Hawryluk writes:
>>
>>> Hi all,
>>>
>>> Long ago I noticed that the text in our PDF manuals is fully black,
>>> which results in rough-looking text
t; without actual content to the
glyphs might be possible, where the total outline is determined by
overlaying all the bounding boxes?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Andrew Hawryluk writes:
> On Thu, Aug 13, 2009 at 7:33 AM, David Kastrup wrote:
>>
>> Sure do. So what driver with what setting converts your PDF to the
>> respective printer language?
>
> Good question.
> At home: Samsung ML-2010, SpliX V. 2.0.0 on Ubuntu 9.0
> box and four attached ghost boxes: I fear that too many ghost boxes
> would dramatically increase the processing time of lilypond...
I think that the two boxes
11
11
222++222
2 11 2
222++222
11
11
should suffice for most pr
an "we need words!"
It would be a shame if an example with the text
text = \lyricmode {
My eyes are dim, I can -- not see,
I have not brought my specs with me!
}
would not include a \markup { \eyeglasses } at an appropriate point.
--
David Kastrup
_
situation?
Not needed. Period at newline is considered sentence ending, always.
That's how I read the docs.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
For some time, my info files (after make info, sudo make install-info)
contain
FIXME: images broken in info
instead of images as before. What happened? Why? Is there a reason,
or a plan to change this again?
--
David Kastrup
___
lilypond
Graham Percival writes:
> On Thu, Aug 27, 2009 at 11:50:13AM +0200, David Kastrup wrote:
>> For some time, my info files (after make info, sudo make install-info)
>> contain
>>
>> FIXME: images broken in info
>>
>> instead of images as before.
Graham Percival writes:
> On Thu, Aug 27, 2009 at 09:10:53PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > On Thu, Aug 27, 2009 at 11:50:13AM +0200, David Kastrup wrote:
>> > I believe this only occurs in general.info, correct? via ma
(define (weird) (append! '(4) '(5)))
guile> (weird)
(4 5)
guile> (weird)
(4 5 . #1#)
guile> (weird)
Backtrace:
In standard input:
7: 0* [weird]
4: 1 [append! (4 5 . #1#) (5 . #0#)]
standard input:4:17: In procedure last-pair in expression (append! (quote #)
(quote #
Graham Percival writes:
> On Fri, Aug 28, 2009 at 08:36:33AM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Well, yes. FIXMEs generally aren't impressive. The FIXMEs will
>> > definitely be dealt with. The images might be dealt
xing all brokenness.
I don't think that an info version of this, the project web page, would
serve a useful purpose, so I think it sensible to completely forget
about "improving" its info aspect (or even its "standalone HTML
documentation" aspect).
--
David Kastrup
__
Carl Sorensen writes:
> On 8/28/09 10:56 PM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> On Aug 28, 2009, at 1:16 PM, "Nicolas Sceaux"
>>> wrote:
>>>
>>>>
>>>> According to R5RS, it
\\, let's take a look at what this actually does, now that we
know how voices are instantiated").
But since it can be used with less brain investment (naming something is
always a chore), it belongs earlier in the introduction to the hopeful
newcomer.
--
David Kastrup
_
s ilk, pretty much everything
looks like a function call without warping.
And that's almost all. A functional programming style without global
variables and states, like
((lambda (f n) (f f n)) (lambda(f n) (if (< n 1) 1 (* n (f f (- n 1) 5)
is not something you'll find in Lilypond.
e all.
>
> Nice try, but *I* was the one who proposed it, *I* was the one to
> organize it, *I* was/am the one who claims to always be concerned
> with managing projects well. What's more, there weren't people
> who (seriously) offered to help and
Martin Tarenskeen writes:
> Hi,
>
> Has someone fixed this little typo in the dutch translation yet:
>
> "kan wellicht geen goede waardestreephelling kunnen vinden"
>
> should be
>
> "kan wellicht geen goede waardestreephelling vinden"
t
> actually seems to be...)
An editor will not interpret control characters. One solution is to
check whether output is sent to a tty and only then use progress
indicators. Or at least overprinting.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
1.
>>
>> (I've always felt this way, too.)
>
> Then let's drop the IMHO unfounded limitation of not breaking at beams
> crossing a barline.
Is there a way to slightly penalize it rather than prohibiting it
completely or being completely unconcerned?
--
David Kastrup
ld appear that \code takes an argument, so the usual usage would
be \code{...}. In the absence of explicit braces, the next token is
digested. This gets turned into
\code{\"}Uber die Nicht-...
effectively, and the \" finds nothing to apply to.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patrick McCarty writes:
> On 2009-09-29, Patrick McCarty wrote:
>> On 2009-09-29, Graham Percival wrote:
>> > On Tue, Sep 29, 2009 at 06:26:08PM +0200, David Kastrup wrote:
>> > > Graham Percival writes:
>> > >
>> > > > l.2850 \entry
}
g^\markup { \Stdbass #21 }
a^\markup { \Stdbass #110 }
b^\markup { \Stdbass #1101 }
} }
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
from
http://www.accordions.com/index/art/stradella.shtml>. I am not
sure it is a good idea to count the contralto with the tenor voice
(making the master be #1121).
But it is four lines (so four digits seems appropriate), and the
contralto does not seem
eyness.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
ly sounding the chord banks as well through mechanical couplers).
So the same mechanisms for tweaking, dot layout specification, register
naming, midi impact, and use should apply.
What kind of data structure can I use such that one can tweak with a
reasonable interface?
--
David Kastrup
Carl Sorensen writes:
> On 10/26/09 1:41 PM, "David Kastrup" wrote:
>>
>> I am working on accordion register symbol typesetting right now. Up to
>> now, there are some font elements in the font, and some basic hackish
>> stuff in the snippets.
>
di stuff needs to be
separate from the typesetting stuff: in a given work for accordion
orchestra, one will use the same kind of symbol everywhere, but possibly
associate different corresponding sound sets with different voices.
So basically this means "don't worry about sound in 1st itera
Carl Sorensen writes:
> Isn't the problem that beams create melismata in vocal music, and you
> don't want to have a line break in the middle of a melisma?
Baroque melisme can go on for lines. Do we have a way to discourage
breaks but not completely disallow them?
-
1 - 100 of 6213 matches
Mail list logo
