On Sun, 20 Mar 2011 00:17:48 -0700, Joe Neeman wrote:
On Sat, Mar 19, 2011 at 11:58 PM, wrote:
In that case, is there any need to set after_affinity at all?
I could ask the author of the original code the same question :)
I think yes. As commentary.
It assures the reader that LilyPond is p
On Mar 15, 2011, at 6:51 PM, Carl Sorensen wrote:
address@hidden wrote Tuesday, March 15, 2011 5:00 PM
\relative c' { \time 3/4 << { 4 2 } \\ { d2. } >> }
Produces the attached output. Is there a way to get it so that the dot
does not collide with the notehead (w/o resorting to extra offsets
On Wed, 16 Mar 2011 06:39:26 -0700, Jan Nieuwenhuizen wrote:
Keith OHara schreef op di 15-03-2011 om 23:09 [-0700]:
I tried to summarize what the relevant classes do, and indicated the
desired extensions in [[ ]] below :
Not really:
* midiChannelMapping = #'instrument (de
On Tue, 15 Mar 2011 13:53:41 -0700, Jan Nieuwenhuizen wrote:
To create a new track for each voice as we do now,
still seems a bit like a kludge to fix MIDI's brokenness.
It is, at least, the same kludge others (classicalmidiconnection.com) use when
they have more than 16 simultaneous lines of
On Tue, 15 Mar 2011 01:50:32 -0700, Jan Nieuwenhuizen wrote:>
1) re-balancing the instruments
Do you have a test file for that?
We have input\regression\midi-volume-equaliser.ly; the equalizer is still
effective, but the values will probably need re-balancing if you implemnt
dynamics differe
On Mon, 14 Mar 2011 14:19:46 -0700, Jan Nieuwenhuizen wrote:
Keith OHara schreef op ma 14-03-2011 om 13:50 [-0700]:
Dynamics are newly implemented as note-on-velocity,
but the old implementation as channel-volume is still there,
What would the correct fix be?
Well, MIDI note-on-velocity
Neil Puttock gmail.com> writes:
>
> Interesting. I was on the right track, but it appears to be deleting
> something which has already been deleted:
>
> Audio_staff*
> Staff_performer::new_audio_staff (string voice)
[..]
>
> In baerenreiter-sarabande.ly, there's an unnamed voice (I'm not sure
On Mon, 14 Mar 2011 02:14:14 -0700, Jan Nieuwenhuizen wrote:
Keith OHara schreef op zo 13-03-2011 om 17:05 [-0700]:
Sensible, but this leaves a partially-finished major change in the
branch that Graham just tagged as 2.14 release candidate.
What's partial about the change?
No
On Sun, 13 Mar 2011 17:10:48 -0700, Graham Percival
wrote:
If there is a critical regression, then go ahead and add an issue
I don't know of any yet, and I will not be looking for any.
The changes within the past week were significant enough that I expect
complaints from people who use MIDI
On Sun, 13 Mar 2011 03:20:51 -0700, Jan Nieuwenhuizen wrote:
I'm not removing anything just yet until we find a good way to
test these things or get some more info.
Sensible, but this leaves a partially-finished major change in the branch that
Graham just tagged as 2.14 release candidate.
D
Keith OHara oco.net> writes:
>
> I see you encode dynamics as MIDI note-on-velocity. (This is much better
> than
> the old way of encoding dynamics as MIDI volume!)
Except that using MIDI volume for dynamics lets LilyPond perform (de)crescendos
on a held note. Somebody mi
On Sat, 12 Mar 2011 12:35:16 -0800, Jan Nieuwenhuizen wrote:
Ok, pushed. Something much like the previous output can still
be selected, just like the voice->channel mapping for reproducing
voice and staff mapping with the current midi2ly.
It generally works.
The MIDI port assignments are s
On Sat, 12 Mar 2011 05:48:08 -0800, Jan Nieuwenhuizen wrote:
Ugh. I have just pushed fixes for setting the instrument and assigning
each track to a new port. It would be nice if you could test it, but
afaics it does not work with timidity, alas.
I see (with hexedit) the new midi events for
On Fri, 11 Mar 2011 10:12:59 -0800, Jan Nieuwenhuizen wrote:
Technical correctness probably has little merit if no player
supports it, but it is worth a try. Setting ports should be
quite easy and if major players support this, we're safe.
I know nothing about this, but some other people wi
On Fri, 11 Mar 2011 01:32:39 -0800, Jan Nieuwenhuizen wrote:
Neil Puttock schreef op do 10-03-2011 om 21:41 [+]:
both voices will still be allocated the same channel
Why would that be a problem? They're in different tracks.
Are you saying that the instrument of channel 0 of track 1
On Thu, 10 Mar 2011 14:11:43 -0800, James Lowe wrote:
I can only describe this as like nailing jelly to a wall.
It's wrecked a load of my scores, and I've taken hours more time getting
what was pretty good in 2.13.40 back to a 'still a bit rubbish' in 2.13.51.
It is probably not worth the ef
On Thu, 10 Mar 2011 11:57:48 -0800, Jan Nieuwenhuizen wrote:>
Commits e5380f2 and 8dc343b break the MIDI output from all the
examples in the documentation that use midiInstrument, and the regtest
‘midi-volume-equaliser.ly’.
It works for me, [...]
Oh! Thanks for checking.
Maybe your midi p
On Thu, 10 Mar 2011 14:11:43 -0800, James Lowe wrote:
\noBreak does little or nothing and trying to expand the MMR does
virtually nothing until I use ridiculous numbers and then it just springs
the two bars on a line on their own.
Golly gee!
\noBreak and/or 'line-break-permission had the des
Jan,
Commits e5380f2 and 8dc343b break the MIDI output from all the examples in the
documentation that use midiInstrument, and the regtest
‘midi-volume-equaliser.ly’. The midi output is much less useful for
proofreading, because all the voices sound the same.
The problem is that the all sett
Neil Puttock gmail.com> writes:
> On 9 March 2011 00:09, Keith OHara oco.net> wrote:
>
> > In 2.13.53, I cannot find a way to make midiInstrument have effect.
>
> Can you post a snippet showing the problem?
Let's use the manual example I linked earlier, but give
James Lowe datacore.com> writes:
>
> What is the \header { } doing to the spacing and how can I prevent it - I
> have tried using a fixed width with a \paper but this does nothing.
>
It seems that any markup on the page causes version 2.13.50+ to prefer
stretching the lines, if one line was for
Is there more to this change, started in commit e5380f2, on the way?
In 2.13.53, I cannot find a way to make midiInstrument have effect.
There is also the problem reported on -bugs
http://lists.gnu.org/archive/html/bug-lilypond/2011-03/msg00152.html
Maybe the previous workaround to have one ch
Phil Holmes philholmes.net> writes:
>
> lyrics-bar.png - the music now breaks over the line to accommodate the text
> mensural-ligatures.ly - one of the staves now disappears over the edge of
> the page.
These two tests suffered somewhat from making keep-inside-line = ##t, so I
adjusted to c
Mike Solomon ufl.edu> writes:
>
> http://codereview.appspot.com/4182071
>
> I have no clue how convert-ly works: would anyone like to take on the task of
implementing these conversions
> in that script?
>
> Cheers,
> MS
Well, eventually somebody has to clean up because your blanket NOT_SMART
Trevor Daniels treda.co.uk> writes:
> > lyrics-bar.png -
>
> This is OK. The "no" is part of the lyrics to the lower staff,
> "no Bar_Engraver_Bar_Engraver_Bar_Engraver" :)
>
> It still shows the bar being pushed out to accommodate the
> long syllable, as it should.
>
LilyPond passes what tha
On Sun, 27 Feb 2011 23:58:45 -0800, Graham Percival
wrote:
Did you intend to remove the dodecaphonic accidentals snippet from our
docs? If so (i.e. it's been replaced with 2.13 functionality), then
we needs some magic in Documentation/snippets/new/ .
Yes; it was obsolete even in version 2.1
On Thu, 24 Feb 2011 19:45:32 -0800, Keith OHara wrote:
... tunings like XX-ET, popular in the 1600s, where C-sharp is 2/5 of a whole
tone above C.
Argh. It is 31-ET that has the 2/5ths. People liked it because it nearly
matched quarter-comma meantone.
I should learn to look things up
Benkő Pál writes:
Graham Breed writes:
> If the accidentals aren't halves, the MIDI production fails.
Please explain in more detail, I never had such problems with MIDI.
The following (derived from an example in the manual) crashes:
\include "makam.ly"
mode = #`((6 . ,(- KOMA)) (3 . ,BAKIYE)
Something good happened recently,
[lily@OHara dvorak]$ time lilypond M*.ly
GNU LilyPond 2.13.46
real34m1.356s
user33m7.193s
sys 0m4.798s
GNU LilyPond 2.13.52
real11m17.441s
user10m39.727s
sys 0m4.129s
Those timings were for the score of a four-movement symphony, and woul
Something good happened recently,
[lily@OHara dvorak]$ time lilypond M*.ly
GNU LilyPond 2.13.46
real34m1.356s
user33m7.193s
sys 0m4.798s
GNU LilyPond 2.13.52
real11m17.441s
user10m39.727s
sys 0m4.129s
Those timings were for the score of a four-movement symphony, and woul
Phil Holmes philholmes.net> writes:
>
> Comparing 13.51 to 13.50 with the official regtest checker shows a plethora
> of minor changes - clearly something in the spacing engine has changed
> enough to flags lots of errors.
Horizontal spacing changed for issue 1229. These all look good to me
On Thu, 17 Feb 2011 21:58:28 -0800, wrote:
On 2011/02/18 05:43:36, Keith wrote:
The extra complication, for which the care was given, makes the system
more difficult to learn, understand, use, and repair.
Unfortunately, I believe that the extra complication is necessary. The
commit message d
On Wed, 16 Feb 2011 08:08:10 -0800, wrote:
On 2011/02/15 18:36:06, Keith wrote:
If there is /any/ protrusion on the lyrics side of the staff,
anywhere in the score, then the PaperColumn skylines used for
note-spacing are built as if lyrics are spaced to clear that
protrusion. The bar-lines th
mike apollinemike.com apollinemike.com> writes:
>
> On Feb 14, 2011, at 6:20 AM, Dmytro O. Redchuk wrote:
>
> > On Mon 07 Feb 2011, 21:17 Werner LEMBERG wrote:
> >>
> >> \header { texidoc = "
> >> The beaming algorithm should handle collisions between beams and
> >> grace notes too.
> >>
> >>
On Mon, 14 Feb 2011 13:43:37 -0800, wrote:
My only concern with these changes is the barline avoidance (which you
mention in the tracker as possibly a good thing). There's one regtest
which shows the problem: in `song-melisma.ly', some extra space has
appeared in the second bar around `daah'.
When compiled with 2.13.49, the amount of whitespace after the barline is
generally smaller, but still isn't corrected for accidental.
Janek, (on -devel so the bug report does not appear to be resolved)
I happened to read the relevant code while looking at issue 1229. The intent
is clearly
On Fri, 11 Feb 2011 23:16:46 -0800, wrote:
On 2011/02/12 06:29:55, Keith wrote:
Phooey. This needs work. Notes on ledger lines below the staff
can slide past the final bar line,
Iff there is only one item in a NonMusicalPaperColumn, then it receives
only the sloped portion of the skyline o
Xavier Scheuer writes:
The only difference I see between GrandStaff and the others is that
GrandStaff does not have "Vertical_align_engraver" .
[...]
Could we add \consists "Vertical_align_engraver" to GrandStaff in
"ly/engraver-init.ly"?
I didn't see a pending patch where this fit
Mike Solomon ufl.edu> writes:
> While trying to eradicate the bug that's been giving me problems today,
> I found this:
> http://lilypond.org/doc/v2.13/Documentation/extending/difficult-tweaks
>
> I think it's the same issue. Das ist nicht gut :(
>
If you are talking about the example under
Xavier Scheuer gmail.com> writes:
>
> The only difference I see between GrandStaff and the others is that
> GrandStaff does not have "Vertical_align_engraver" .
>
[...]
> Could we add \consists "Vertical_align_engraver" to GrandStaff in
> "ly/engraver-init.ly"?
>
Absolutely, yes.
I a
Phil Holmes philholmes.net> writes:
> [...]typography-demo.ly [...] used to occupy 3 lines - it's now 4
> lines. Don't believe this counts as a regression.
>
This one doesn't have its images compared in a make check, so I hadn't noticed
that change. My patch prevents the fermata from overla
My issue-1500 patch slightly increased horizontal spacing in several regtests
(reversing some of the tightening seen in the change from 2.13.24 to .25)
I changed 'lyrics-melisma-beam.ly' to make it more sensitive to spacing bugs
similar to issue 1200.
Pál changed 'mensural-ligatures.ly' and perh
On Fri, 04 Feb 2011 11:01:02 -0800, Janek Warchoł
wrote:
Please tell me what you think.
Graham, Han-Wen, Reinhold, Keith - may i ask for your opinion too?
After all, this changes will affect virtually all scores (all notes on
middle line of the staff will have longer stems, not mentioning othe
On Thu, 03 Feb 2011 17:43:38 -0800, wrote:
not a patch comment, but I'm intrigued -- how often do you think that
people use automatic ties?
I had never used them or seen them used.
But the moment I started playing with \retrograde, on a melody that did not
fill an integral number of measures
Mike Solomon ufl.edu> writes:
>
> It seems that the variable `measures' is unused in this function - can this
> be
deleted?
>
Who are you asking? git blame ("git credit" would have been a nicer name)
shows these lines have not been touched in several years, so it is not likely
to be in a
On Mon, 24 Jan 2011 20:47:24 -0800, wrote:
This patch also resolves the problem in issue 1229 of notes extending
beyond the right-hand bar line.
Adding additional extra-spacing-height to the TimeSignature grob
resolves the 1229 issue of overlapping the time signature.
This patch seems to have
Original Message
> Somebody this weekend posted, either in an email or in an issue comment,
> that they were finally able to upload patches to Rietveld.
That was me, in an issue comment explaining why my first patch set was
bad.
I intended to follow-up to say that Python finds
On Thu, 20 Jan 2011 01:33:10 -0800, Keith OHara wrote:
... because that fixes 1120 more
solidly and removes the cause for issues 1474 and 1472,
Well, reverting ee0488 removes the cause of our /noticing/ issue 1472
(multi-measure rests colliding with key signatures).
The way that KeySigs
%{ Fellow Contributors,
The patches look like they do the job, and give clean regression tests,
but the developers are hesitant. I am not a programmer, and I cannot
read minds, but I can tell you what makes *me* hesitant.
Look at issue 1120. A lyric syllable covering more than one note spread
th
Carl Sorensen byu.edu> writes:
> So what is the current status on 1474?
>
> I think that the latest proposal from Keith O'Hara was to revert ee0488.
>
Issue 1474 looks like intentional behavior to me, and non-regressive to
Janek. We'll see what Bernard says after he gives this a fresh look w
On Sat, 18 Dec 2010 15:56:25 -0800, Keith OHara wrote:
On Fri, 10 Dec 2010 01:46:24 -0500 James Lowe wrote:>
<http://lilypond.org/doc/v2.13/Documentation/notation/multiple-voices#Known-issues-and-warnings-30>
PS To anyone else who knows, if this known issue does apply in this case,
On Sun, 16 Jan 2011 01:51:19 -0800, Trevor Daniels
wrote:
I've pushed this patch, but isn't the immediately preceding text
misleading,
in that it says,
"The following example demonstrates the two ways these alists can be
modified. The first declaration updates one key-value individually,
and
James Worlton gmail.com> writes:
The following code compiles, but the spacing override in the layout block fails. The
layout block code was copied and pasted into my test directly from the NR 4.4.1
"Within-system spacing properties". ...
\override VerticalAxisGroup #'staff-staff-spacing #'b
On Sat, 15 Jan 2011 03:26:47 -0800, Keith OHara wrote:
On Fri, 14 Jan 2011 03:20:15 -0800, Joe Neeman wrote:
I think you'll find that the regression was caused by ee0488,
Yes. Reverting the commit to fix 1120, from current master :
[...]
+ and for some reason correctly spaces notes
Graham Percival percival-music.ca> writes:
> Oh, ok. It would have been nice if somebody had added this to the
> issue tracker. I've added the patch there.
>
When the bug reports get immediate replies or questions, there is a tendency to
wait for the discussion to die down before opening a n
On Thu, 13 Jan 2011 03:23:16 -0800, Mike Solomon wrote:
I think that the case you're talking about (<< e'32. \\ e'2>>) is a problem
with my code, which triggers stem raising for flags that fall on the right even though
these flags do note cause intersection problems. Is there a good way to
Original Message
> Only unnecessary lengthening now is some stems on
> cue notes, but it really sticks out.
Well, as they say, "pictures or it didn't happen" The cue from the
trumpets looks desperate for attention.
> I could only reduce it to four
> required ingredients: manu
Mike,
I like it on small scores.
I let your patch compile a symphony and got several unneeded stem
lengthenings per page. I started carving out a reasonable-sized .ly to
send for you to test, but that might actually take longer than you
recognizing the problem from the output. Three images at
On Sat, 08 Jan 2011 06:19:16 -0800, Carl Sorensen wrote:
On Fri, 07 Jan 2011 15:50:40 -0800, Carl Sorensen wrote:
A default value of skyline-horizontal-padding of 1.2 gets
skyline-horizontal-padding.ly to work well.
An override to System 'skyline-horizontal-padding = #0 in
stem-length-estima
On Fri, 07 Jan 2011 15:50:40 -0800, Carl Sorensen wrote:
A default value of skyline-horizontal-padding of 1.2 gets
skyline-horizontal-padding.ly to work well.
An override to System 'skyline-horizontal-padding = #0 in
stem-length-estimation.ly gets it working well. Since we already have
overri
Original Message
> From: "Carl Sorensen"
> Sent: Friday, January 07, 2011 3:28 PM
>
> I was hoping that by setting the default, we'd get good spacing and we
> wouldn't need the override.
>
I hadn't seen this exchange when I commented on the define-grobs.scm;
sorry.
The larg
Original Message
> From: "Mike Solomon"
> Sent: Thursday, January 06, 2011 10:03 AM
>
Mike,
The patch moves 8th notes unnecessarily.
The patch breaks the collision resolution of dotted notes.
If you have to move the notehead, you're moving it the wrong direction.
Test musi
Mike Solomon ufl.edu> writes:
> I've included before and after photos.
Hi Mike.
The hemidemisemiquaver(*) and the minim are supposed to be simultaneous, so I
do not like the horizontal shift.
There is no mention in issue 39 of the desired output. The only thing I can
imagine wanting done auto
Phil Holmes philholmes.net> writes:
> \remove "Hara_kiri_engraver"
> \consists "Hara_kiri_engraver"
>
> I know I don't properly understand this stuff still, but doesn't the
> \consists re-instate the previously removed engraver on the line above?
>
You are correct.
I looked at the history
On Fri, 31 Dec 2010 16:31:23 -0800, Trevor Daniels
wrote:
... the concern I had was this. Quite a lot of the
documentation was written, not by inspecting the code
to see what was intended, but by experimenting and
writing up what was found. I certainly worked that
way, and I think Mark and Ke
Trevor Daniels treda.co.uk> writes:
> Graham Percival wrote Thursday, December 30, 2010 3:56 AM
> >
> > I want to keep the word "intentionally", though -- if something
> > only happened to work because of a happy coincidence of bugs, then
> > "breaking" that should not be a Critical bug.
>
> I'm
On Fri, 24 Dec 2010 00:54:38 -0800, wrote:
[...]I would prefer to see the original example retained to show in the starkest
fashion how staves should be changed manually, with this one added later
to show the possibility of collisions.
That's a better way to do it. The attached patch reverts
Original Message
> From: tdanielsmu...@googlemail.com
> Keith, could you please fix the haripins, decide on the wording you
> prefer, and let me have a patch to push.
>
Patch attached, and issue closed.
-Keith
0001-patch-from-issue-3743045.patch
Description: Binary data
__
We decided not to document this earlier because it is logged in the tracker
(issues 36, 439, 721, 1324, 1411).
However, searching the code for 'cross-staff', I see that allowing some
collisions is clearly intentional. After thinking a bit, it becomes clear that
some collisions must be allowed
Patch created by lily-git.tcl
-Keith
0001-Doc-NR-new-dynamics-context-cresc.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
501 - 570 of 570 matches
Mail list logo
