In this connection, you may like to note that the upcoming Denemo
release will allow you to play back via an internal synth using
microtonal accidentals and, of course, print out using whatever LilyPond
syntax you program Denemo to use.
An example in Denemo's git at the moment uses the mechanism
Apart from the placement of the descriptive text in the IR, which I
think is debatable, I agree with Carl's comments.
Thanks again Mark. Every iteration is an improvement. I think we're
nearly there!
Trevor
http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc
File
On 2010/11/12 09:06:06, Trevor Daniels wrote:
http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc#newcode780
lily/axis-group-interface.cc:780: The following keys may be set in
the spacing
alists:\n
I'm not sure. The current description is in the interface.
If
I am writing a very-simplified LilyPond parser, just to analyze the notes,
chords and rests/silences within a particular { }-block of LY code. I want
to completely ignore all non-note (and non-chords and non-rest/silence)
elements.
I am trying to understand all of the (at least most common)
Hello,
http://codereview.appspot.com/3061041
This is from
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00177.html
I hope this is ok. This is the first time I have
i. applied someone else's code to my source code
ii. uploaded to Rietveld
so if there is something wrong with the
On 11 Nov 2010, at 18:47, Erich Enke wrote:
Thank you for the pointers. Since translation to Western notation
remains a goal of mine, it would make sense to develop the staff
notation. The responses were encouraging enough that I'll begin
looking into implementing this in lilypond.
I have
Am Freitag, 12. November 2010, um 15:16:20 schrieb James:
http://codereview.appspot.com/3061041
This is from
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00177.html
Just for completeness, these are the settings that I have found to produce
quite good results for my
oops, we were missing the CC to lilypond-devel.
The patch looks generally ok to me, but I'm not up to speed on spacing
stuff.
Keith: why are you removing the #'stretchability = 5 ? What's the
default value if you remove it?
James: I suggest that the next version of the patch uses the same
You're right, Carl. I'd misunderstood how this works.
Trevor
http://codereview.appspot.com/3031041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Nov 12, 2010 at 7:04 AM, Reinhold Kainhofer
reinh...@kainhofer.comwrote:
What I don't really understand why the stretchability of the StaffGrouper
in
staves/scores contexts seems to have a completely different unit than the
stretchability defined in the \paper block. I would have
I see that interfaces come to the IR from at least three
different types of places:
1) lily/[grobname].cc (e.g. accidental)
2) lily/[grobname]-interface.cc(e.g. align)
3) scm/define-grob-interfaces.scm (e.g. ambitus)
Is there a system to this organization? Is it optimal?
It's
On 2010/11/12 02:46:18, Carl wrote:
Thanks again for your work on this, Mark.
Carl, I think that everything you wrote in this post is
agreeable, including changing the StaffGrouper property name
to default-staff-staff-spacing. I'm happy to implement
all of these changes, but this will have to
On 12 November 2010 17:03, Mark Polesky markpole...@yahoo.com wrote:
I see that interfaces come to the IR from at least three
different types of places:
1) lily/[grobname].cc (e.g. accidental)
2) lily/[grobname]-interface.cc (e.g. align)
3) scm/define-grob-interfaces.scm
On 2010/11/12 04:12:48, Carl wrote:
Here's a new version of the patch that tries to eliminate any scheme
calls, and
demonstrates my problem.
I need to do a check on the left bound to see if it's a grob, because
if I take
the check out I get a Bus error.
I don't know how to do such a
http://codereview.appspot.com/3061041/diff/1/ly/engraver-init.ly
File ly/engraver-init.ly (left):
http://codereview.appspot.com/3061041/diff/1/ly/engraver-init.ly#oldcode322
ly/engraver-init.ly:322: \override StaffGrouper #'between-staff-spacing
#'stretchability = #5
On 2010/11/12 14:55:28,
On Fri, 12 Nov 2010 09:00:02 -0800, lilypond-devel-requ...@gnu.org wrote:
On Fri, Nov 12, 2010 at 7:04 AM, Reinhold Kainhofer
What I don't really understand why the stretchability [...] in
staves/scores contexts seems to have a completely different unit than the
stretchability defined in the
On Fri, 12 Nov 2010 09:00:02 -0800, lilypond-devel-requ...@gnu.org wrote:
On Fri, Nov 12, 2010 at 7:04 AM, Reinhold Kainhofer
What I don't really understand why the stretchability [...] in
staves/scores contexts seems to have a completely different unit than the
stretchability defined in the
On 2010/11/12 17:19:17, Mark Polesky wrote:
Trevor, any objection to Carl's renaming? It's logical and
consistent in my mind, so I'd like to do it.
Sorry to keep changing my mind... In truth I'm still questioning it.
I might like to keep staff-staff-spacing for the StaffGrouper prop.
I'm
On 2010/11/12 21:53:41, Mark Polesky wrote:
I might like to keep staff-staff-spacing for the StaffGrouper
prop. I'm thinking it over, and I'll get back to you.
Guys, I'd rather not change StaffGrouper's
'staff-staff-spacing to 'default-staff-staff-spacing. The
big reason for me is that it is
On 2010/11/12 22:48:57, Mark Polesky wrote:
staff-staff-spacing
When applied to a staff-group's StaffGrouper grob, this
spacing alist controls the distance between consecutive
staves within the staff-group. When applied to a staff's
VerticalAxisGroup grob, it controls the distance between
On 2010/11/12 17:19:17, Mark Polesky wrote:
On 2010/11/12 02:46:18, Carl wrote:
One tiny modification I propose is to put the alist-key
descriptions into default-staff-staff- instead of
staff-staff- because otherwise the prop descriptions on
the IR staff-grouper-interface page would be referring
Neil Puttock wrote:
Scheme definitions are only used for interfaces which
either have no code (e.g., dynamic-interface) or have
callbacks defined solely in scheme.
You probably think this is silly, but any objection to me
adding this near the top of define-grob-interfaces.scm?
;; The
On 11/12/10 4:11 PM, Mark Polesky markpole...@yahoo.com wrote:
Neil Puttock wrote:
Scheme definitions are only used for interfaces which
either have no code (e.g., dynamic-interface) or have
callbacks defined solely in scheme.
You probably think this is silly, but any objection to me
markpole...@gmail.com wrote Friday, November 12, 2010 10:48 PM
On 2010/11/12 21:53:41, Mark Polesky wrote:
I might like to keep staff-staff-spacing for the StaffGrouper
prop. I'm thinking it over, and I'll get back to you.
Guys, I'd rather not change StaffGrouper's
'staff-staff-spacing to
Here's the latest patch set.
I think I made every suggestion except one. I didn't
change grob to layout object, just because grob
appears as a word so often in define-grob-properties.scm,
and layout doesn't appear once:
$ git grep -c -e \grob\ --and --not -e [-:]grob \
On 2010/11/13 00:50:51, Mark Polesky wrote:
So, could it possibly be? Is this okay to push?
I like it a lot!
Just one more thing -- James has captured new default values from Keith
Ohara's work. Perhaps these new default values should be added as part
of this patch.
LGTM.
What happened to the description of reference points for various
objects? Has that disappeared, or did I just miss it?
Will it be coming back somewhere?
Thanks,
Carl
http://codereview.appspot.com/3031041/diff/64001/Documentation/learning/fundamental.itely
File
James,
I just pushed my patch which renames the vertical spacing
grob properties, which directly affects your patch here, and
will likely require resolving conflicts in git (which can be
annoying sometimes, especially when you haven't done it
before). Looks like it will be fairly straightforward
Carl and Trevor,
The patch is pushed. Thanks so much for your help!
On 2010/11/13 01:10:47, Carl wrote:
But this change will invalidate James's patch, so we ought
to at least be sure to handle that properly.
Yep. I emailed him on -devel.
What happened to the description of reference
On 11/12/10 6:56 PM, markpole...@gmail.com markpole...@gmail.com wrote:
Does this require a change here?
Yes. This was written in July with commit #6734448, and
Neil fixed the issue two weeks ago with commit #93c53eb.
Best to fix it now or make a note of it somewhere other than
this
Joe,
all votes are in except yours, which is kind of a moot point
anyway, since (if you're still up for it) you'll be the one
actually making this change:
1) basic-distanceminimum-distance
2) initial-distanceminimum-distance
3) basic-separation minimum-separation
4)
Thanks for the help on the null pointer. I was thinking that it was
some *other* kind of variable than a Grob, and that I was casting it
wrong.
Got that all taken care of -- no scheme calls at all.
On 2010/11/12 17:40:42, Neil Puttock wrote:
It's back to square one though, isn't it?
The
32 matches
Mail list logo
