Dan Wilckens wrote Thursday, July 29, 2010 2:47 PM
Hi James,
I mainly thought the tempo command was too hard to find in the
documentation--too illogically placed for me to track down easily
navigating the notation reference headings (just tried it in the
2.13 doc's, had similar problems be
Carl Sorensen wrote Thursday, July 29, 2010 10:24 PM
On 7/29/10 12:07 PM, "James" wrote:
On 29/07/2010 18:19, Mike Solomon wrote:
Hey Bernardo,
The woodwind fingering is chugging along. All of the code
is in the
current development version of lilypond, along with some
regression tes
On Thu, Jul 29, 2010 at 07:07:53PM +0100, James wrote:
> On 29/07/2010 18:19, Mike Solomon wrote:
>> Hey Bernardo,
>> The woodwind fingering is chugging along. All of the code is in the
>> current development version of lilypond, along with some regression tests
>> showing the functionality o
On Thu, Jul 29, 2010 at 08:17:38PM +0200, Mike Solomon wrote:
> True that.
Please do not top-post.
> My three.5 concerns are:
> 1) said code cannot use non-public scheme functions (am I right in thinking
> that?).
I'm not certain about this.
> 2) changes to init.ly are not copied from one versi
On 7/29/10 12:07 PM, "James" wrote:
> On 29/07/2010 18:19, Mike Solomon wrote:
>> Hey Bernardo,
>> The woodwind fingering is chugging along. All of the code is in the
>> current development version of lilypond, along with some regression tests
>> showing the functionality on all of the i
On 2010/07/13 15:02:56, Carl wrote:
On 2010/07/11 23:31:50, Neil Puttock wrote:
> beam-type ?
I think not, because we're not talking about an argument to a function
call or
an entry in an alist here. We're talking about something that comes
from the
music. But I could be convinced other
On 2010/07/29 20:05:30, dak wrote:
I don't think that convert-ly is supposed to deal with Scheme markup
conversion.
Searching for #: in the convertrules turns up exactly nothing.
Why would it? You don't need that to catch all three types, since the
important part is the glyph string.
htt
On 2010/07/29 19:29:39, Neil Puttock wrote:
http://codereview.appspot.com/1908041/diff/2001/3003
File python/convertrules.py (right):
http://codereview.appspot.com/1908041/diff/2001/3003#newcode3044
python/convertrules.py:3044: str = re.sub
(r'(\\musicglyph\s*#"accordion\.)([a-zA-Z]+)"',
Could
Interesting...thank you.
I completely missed that. Sorry for the clutter :-(
On 7/29/10 9:36 PM, "Neil Puttock" wrote:
> On 29 July 2010 20:34, Mike Solomon wrote:
>> I think that this patch is the easiest way to assure that the break
>> processing will happen when do_break_processing is call
On 29 July 2010 20:34, Mike Solomon wrote:
> I think that this patch is the easiest way to assure that the break
> processing will happen when do_break_processing is called (although I could
> be wrong), whereas creating a grob doesn't get you a spanner's break
> processing.
Have you looked at th
http://codereview.appspot.com/1908041/diff/2001/3003
File python/convertrules.py (right):
http://codereview.appspot.com/1908041/diff/2001/3003#newcode3044
python/convertrules.py:3044: str = re.sub
(r'(\\musicglyph\s*#"accordion\.)([a-zA-Z]+)"',
Could be more generic, since it won't convert schem
I think that this patch is the easiest way to assure that the break
processing will happen when do_break_processing is called (although I could
be wrong), whereas creating a grob doesn't get you a spanner's break
processing.
On 7/29/10 9:14 PM, "Neil Puttock" wrote:
> On 29 July 2010 19:22, Mike
On 2010/07/29 00:55:35, Patrick McCarty wrote:
With your patchset, I am getting a compile failure with the regression
test
`profile-property-access.ly':
Same here.
+ = scm_list_3 (ly_symbol2scm ("module-use!"), mod, used);
This effectively exports all bindings, so all local defines are now
On 29 July 2010 19:22, Mike Solomon wrote:
> Name says it all.
Why do you need this?
Since a Spanner's parent class is Grob, ly:engraver-make-grob should
have no problem creating spanners.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@g
Name says it all.
http://codereview.appspot.com/1869047
Disregard the changes to lily-guile.hh - all of my patches uploaded with
git-cl spit that out because of Mac OS X 10.4 powerpc modifications I had to
make to get lilypond compile-able.
To apply the patch set directly (w/o the lily-guile.hh
True that.
My three.5 concerns are:
1) said code cannot use non-public scheme functions (am I right in thinking
that?).
2) changes to init.ly are not copied from one version of lilypond to the
next, nor are one person's "modules". I do my compiling from the git
repository, so I could likely rig s
On 29/07/2010 18:19, Mike Solomon wrote:
Hey Bernardo,
The woodwind fingering is chugging along. All of the code is in the
current development version of lilypond, along with some regression tests
showing the functionality on all of the instruments. It just needs people
to write documentat
On Wed, Jul 28, 2010 at 04:25:08PM +0200, Mike Solomon wrote:
> 1) A folder would be created in (ie PATH/lilypond/2.X.X/module) in which
> all modules hung out so that Lilypond knew to look there. Each module would
> have its own folder and could be internally organized however one fancies.
Kind
On 2010/07/29 13:01:47, c_sorensen_byu.edu wrote:
Right now you have put these conversions into a separate rule. Add
them to
the 2.13.29 rule. Then I think you have to do make to get the rules
into
convert-ly, but I'm not sure on that.
You might need to do something like
make -C scripts
19 matches
Mail list logo
