[Patch] 'transparent vs. 'whiteout

[Marc Hohl]

Hello all,

after some discussions on the frog list I created a patch improving the
use of the 'transparent property. As Neil suggested, an invisible grob
should have no whiteout, and this is what the patch does.

After grepping through the code, I don't think that this will influence the
overall use of 'whiteout and 'transparent, but it will make things much 
easier

for tablature.

Marc

http://codereview.appspot.com/1681043


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to develop Emacs mode?

[Nicolas Sceaux]

Le 17 juin 2010 à 17:31, David Kastrup a écrit :

> Carl Sorensen  writes:
> 
>> On 6/17/10 8:59 AM, "David Kastrup"  wrote:
>> 
>>> 
>>> 
>>> Hi,
>>> 
>>> I have a question about developing Emacs input and major modes for
>>> Lilypond.  What would be the right way to go forward for me?
>>> 
>>> I want to make use of current Emacs features (like semantic parsing and
>>> similar).  I also want to create input methods for inputting on the
>>> keyboard in chromatic button keyboard layout, but also in parallel for
>>> inputting via midi (I already checked that make-serial-process can be
>>> used for opening and accessing a midi device on GNU/Linux).
>> 
>> Are you familiar with lyqi?
>> 
>> 
> 
> Not chromatic button accordion layout, and I should think that a regular
> input method might be cleaner.  I think I checked it out at one time,
> and the payback for the installation trouble seemed not convincing to
> me.  In particular, French note names were not interesting to me.  I
> should think that the canonical input method should be Dutch.

Err, I should do something about this link which is totaly outdated.
But, for the record, Dutch input method was of course the default, not
French.

I've been writing a new version with a home made parser (see
http://github.com/nsceaux/lyqi) because I was under the impression
that semantics (http://cedet.sourceforge.net/semantic.shtml) was not
responsive enough with respect to incremental parsing, but I may well
be wrong[1].  Indentation is not good yet, but at least the parser as
knowledged of lilypond/scheme/lilypond embedding.  Anyway, it seems
that I've reinvented the wheel (badly).  On the other hand my note
typing as never been so quick.

Several years ago, I used a midi keyboard to enter the notes: one hand
on the midi keyboard, and one hand on the computer keyboard, to set
durations, because I'm a lame keyboard player.  But it turned out that
(in my case) that method was not quicker (or practical) than full computer
keyboard entry.

Nicolas

[1]  Its documentation says that parsing happens mainly in idle
time, whereas I needed that it happens as soon as a typing command is
done (so that the next command can immediately know what the previous
note duration, alteration, etc, is, to modify it).
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to develop Emacs mode?

[David Kastrup]

Nicolas Sceaux  writes:

> Le 17 juin 2010 à 17:31, David Kastrup a écrit :
>
>> Carl Sorensen  writes:
>> 
>>> On 6/17/10 8:59 AM, "David Kastrup"  wrote:
>>> 
 I have a question about developing Emacs input and major modes for
 Lilypond.  What would be the right way to go forward for me?
 
 I want to make use of current Emacs features (like semantic parsing
 and similar).  I also want to create input methods for inputting on
 the keyboard in chromatic button keyboard layout, but also in
 parallel for inputting via midi (I already checked that
 make-serial-process can be used for opening and accessing a midi
 device on GNU/Linux).
>>> 
>>> Are you familiar with lyqi?
>>> 
>>> 
>> 
>> Not chromatic button accordion layout, and I should think that a
>> regular input method might be cleaner.  I think I checked it out at
>> one time, and the payback for the installation trouble seemed not
>> convincing to me.  In particular, French note names were not
>> interesting to me.  I should think that the canonical input method
>> should be Dutch.
>
> Err, I should do something about this link which is totaly outdated.
> But, for the record, Dutch input method was of course the default, not
> French.

Yes, I mentioned in a followup that I apparently have been quite
careless in rereading the lyqi information.  I think the first time I
gave up on lyqi could possibly have been because of running out of steam
satisfying the dependencies, contrasted with the expected return of
investment.

> I've been writing a new version with a home made parser (see
> http://github.com/nsceaux/lyqi) because I was under the impression
> that semantics (http://cedet.sourceforge.net/semantic.shtml) was not
> responsive enough with respect to incremental parsing, but I may well
> be wrong[1].  Indentation is not good yet, but at least the parser as
> knowledged of lilypond/scheme/lilypond embedding.  Anyway, it seems
> that I've reinvented the wheel (badly).  On the other hand my note
> typing as never been so quick.

Well, being used to your tools is always helpful.

> Several years ago, I used a midi keyboard to enter the notes: one hand
> on the midi keyboard, and one hand on the computer keyboard, to set
> durations, because I'm a lame keyboard player.  But it turned out that
> (in my case) that method was not quicker (or practical) than full
> computer keyboard entry.

I should think so.  I am not a good keyboard player either.  But I think
that recording with complete timing, and placing the bar lines manually
afterwards should allow for an excellent return of invested time.
Managing reasonably timed keyboard input for a bar at a time should be
doable.  And if you mess up one bar completely, you can still relabel
all of it manually.

> [1] Its documentation says that parsing happens mainly in idle time,
> whereas I needed that it happens as soon as a typing command is done
> (so that the next command can immediately know what the previous note
> duration, alteration, etc, is, to modify it).

I think that semantic does "idle time" parsing mostly for cross
reference information and similar.

It would appear pretty nonsensical for me to ignore your work on lyqi
(which, in turn, appears to be slated to replace most of the existing
lilypond-mode functionality).  If it is compatible with your plans
(which may include copyright assignment) to have a full-featured
Lilypond mode eventually appear upstream in Emacs, I'd just try joining
forces with you.

It would appear that you work on MacOSX or so.  Can you check whether
some variation of the Midi test code using make-serial-process I posted
recently could be made to work on your setup?  If it did, this would be
much preferable to having to use external applications like rumor.

Thanks

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MetronomeMark placement questions

[Carl Sorensen]

On 6/18/10 10:07 PM, "Kieren MacMillan" 
wrote:

> 
> In the short term, I'm considering creating a Tempo context, which only prints
> out tempo indications (akin to the TimeSig context of yore). This context
> could then be placed in the \score wherever one needs it, solving (1), (2),
> and (4); since the context would be independent of any other contexts, (3) is
> automagically solved. But I want this to be easy to implement, so I either
> want the Tempo context to automagically ignore everything except MetronomeMark
> grobs, or I need to build a function/macro to strip out everything except
> MetronomeMark grobs.
> 
> Q#1: Which of those two options is programatically superior?

The first option is best, in my opinion.  But there is one subtle
difference.  Contexts don't *handle* grobs, they *create* grobs (actually,
they contain engravers which create grobs).  So your Tempo context will
contain the Metronome_mark_engraver, and will automatically ignore
everything except the events that the Metronome_mark_engraver listens to.

The down side to this approach is that you will need to have a separate
music expression to pass to the Tempo context.  I suppose that this
expression can be the "master" expression (i.e. the expression that contains
just skips and Tempo indications).  But it seems like a bit of a pain.

> 
> Q#2: In the long term, would the short term solution still be the best, or
> should Lilypond Do The Right Thing in some other way that doesn't require a
> separate context?

I can't think of another way to do it, but it would be nice if the
Staff_grouping_engraver could DTRT, i.e. put the metronome mark above the
first printed staff below some indicated staff.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to develop Emacs mode?

[Nicolas Sceaux]

Le 19 juin 2010 à 14:23, David Kastrup a écrit :

> It would appear pretty nonsensical for me to ignore your work on lyqi
> (which, in turn, appears to be slated to replace most of the existing
> lilypond-mode functionality).

Indeed, I do not use LilyPond-mode anymore.

> If it is compatible with your plans
> (which may include copyright assignment) to have a full-featured
> Lilypond mode eventually appear upstream in Emacs, I'd just try joining
> forces with you.

I'm not protective about this emacs mode.  Just interested in having
something as effective as possible wrt note entry, because I type a lot
of music.

> It would appear that you work on MacOSX or so.  Can you check whether
> some variation of the Midi test code using make-serial-process I posted
> recently could be made to work on your setup?  If it did, this would be
> much preferable to having to use external applications like rumor.

My machine does not have a serial port, and I don't have a midi keyboard
anymore.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [Patch] 'transparent vs. 'whiteout

[Carl Sorensen]

Marc,

The code looks great to me.  Please email me a patch (so it will have you as
the author) and I will push it.

Thanks,

Carl


On 6/19/10 3:11 AM, "Marc Hohl"  wrote:

> Hello all,
> 
> after some discussions on the frog list I created a patch improving the
> use of the 'transparent property. As Neil suggested, an invisible grob
> should have no whiteout, and this is what the patch does.
> 
> After grepping through the code, I don't think that this will influence the
> overall use of 'whiteout and 'transparent, but it will make things much
> easier
> for tablature.
> 
> Marc
> 
> http://codereview.appspot.com/1681043
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to develop Emacs mode?

[Laura Conrad]

> "Nicolas" == Nicolas Sceaux  writes:

Nicolas> Several years ago, I used a midi keyboard to enter the notes: one 
hand
Nicolas> on the midi keyboard, and one hand on the computer keyboard, to set
Nicolas> durations, because I'm a lame keyboard player.  But it turned out 
that
Nicolas> (in my case) that method was not quicker (or practical) than full 
computer
Nicolas> keyboard entry.

I do use that method still.  I find it's not a lot quicker, but is a
bit less error prone, for my purposes.  When I do "relative" entry
from the computer keyboard, I make a lot of octavation errors.

But I agree with David that it needs better intelligence about
enharmonic notes -- if I weren't doing Renaissance music, which has a
lot higher percentage of "white notes" than later styles, I might well
decide that fixing the enharmonics was taking as much time as I was
saving on the octavation errors.

Another thing I'd really like added to this input method is a way to
hear the MIDI notes.  

-- 
Laura   (mailto:lcon...@laymusic.org)
(617) 661-8097  233 Broadway, Cambridge, MA 02139   
http://www.laymusic.org/ http://www.serpentpublications.org

Copyright law has abandoned its reason for being: to encourage
learning and the creation of new works. Instead, its principal
functions now are to preserve existing failed business models, to
suppress new business models and technologies, and to obtain, if
possible, enormous windfall profits from activity that not only causes
no harm, but which is beneficial to copyright owners.

William Patry, in his farewell post on "The Patry Copyright Blog".


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Clarify vertical spacing with an example

[Graham Percival]

I'm slightly uncomfortable giving "default values" in an .itely file,
but IIRC the rest of spacing.itely does that anyway, so whatever.
Thanks, pushed.

Cheers,
- Graham


On Sun, Jun 13, 2010 at 4:29 PM, Francisco Vila  wrote:
> Hello,
> The attached patch adds a minimal example of what the new vertical
> spacing commands look like.
>
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to develop Emacs mode?

[David Kastrup]

Nicolas Sceaux  writes:

> Le 19 juin 2010 à 14:23, David Kastrup a écrit :
>
>> It would appear that you work on MacOSX or so.  Can you check whether
>> some variation of the Midi test code using make-serial-process I posted
>> recently could be made to work on your setup?  If it did, this would be
>> much preferable to having to use external applications like rumor.
>
> My machine does not have a serial port,

Neither has mine.  I just use make-serial-process's ability to actually
work with any character device for attaching it to a midi port.  The
actual Midi connection happens to be a USB Midi converter.

> and I don't have a midi keyboard anymore.

It should work with any application providing a midi device.  For
example, under GNU/Linux you'll find virtual Midi keyboards which
deliver Midi events for mouse clicks on the screen image of a piano
keyboard.

If you could find anything like that for MacOSX, it should be fine for
testing.  But of course, if you would not make use of that functionality
yourself, you can just wait until somebody else using MacOSX provides
relevant feedback with regard to that particular item.

It is not like you don't have anything else to do...

Oh, by the way.  I have a 49-key USB Midi master keyboard (M-Audio eKeys
49) sitting around here, standard-compliant (just Plug&Play with Linux)
and of rather low weight (something like 3kg or so) and moderate size
(49 keys are 49 keys, but there is not much else).  If you port the
stuff I am planning to do over to the MacOSX side and seriously test
what makes and what does not make it work well for you for a while, it's
yours.  You have to provide your own stand or table for it, though.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MetronomeMark placement questions

[Kieren MacMillan]

Hi Carl,

> The first option is best, in my opinion.

Thanks.

> The down side to this approach is that you will need to have a separate
> music expression to pass to the Tempo context.  I suppose that this
> expression can be the "master" expression (i.e. the expression that contains
> just skips and Tempo indications).  But it seems like a bit of a pain.

If the context ignores everything else, why can't I just put my \global in 
there?

> it would be nice if the Staff_grouping_engraver could DTRT,
> i.e. put the metronome mark above the first printed staff below some 
> indicated staff.

Perhaps a property can [eventually] be added to determine which StaffGroup 
grobs need MMs above and which need MMs below.

Thanks!
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MetronomeMark placement questions

[Xavier Scheuer]

2010/6/19 Kieren MacMillan :

> Hey y'alls,
>
> I'm trying to solve the age-old [for me] problem of MetronomeMark
> placement.

:-)
I complained a lot about the bad "tempo indications" placement, I'm
really glad to see people trying to solve it.
Thanks!


> There are [at least] four issues that need to be solved simultaneously:
>  (1) MMs [almost always] need to be at the top of each system;

Well, this is already the case, isn't it?
"Staff_collecting_engraver" takes care of that for both RehearsalMark
and MetronomeMark, which is fine.


>  (2) MMs potentially need to be other places (e.g., bottom of each
> system, or mid-system between two staff groups);

Ususally, when not printed at the top of the whole system it is (based
on my own experience with scores from IMSLP):

  a. either printed at the top and at the bottom of the whole system,
 which is not possible to do _correctly_ right now.
 We could use the trick of LSR 10 but that would simply add
 "Metronome_mark_engraver" to the lowest staff, and won't handle
 correctly the case of removed Staff (\RemoveEmptyStaffContext).


To solve this I could imagine something like

  \set doubleMetronomeMarks = ##t

(inspired by "\set doubleSlurs = ##t"), that would print MetronomeMark
at both the top and the bottom of the context it applies to (Score).

NOTE: The problem is *exactly* the same for RehearsalMarks !!!
  That you be great to solve it the same way.


  b. MM printed at the top of the whole system _and_ at the top of a
 StaffGroup (normally "strings" for pieces like symphonies) inside
 the system.
 We can already handle this easily by adding
 "Metronome_mark_engraver" to this StaffGroup and removing
 "Staff_collecting_engraver" for the Score context.


  c. MM printed at the top _and_ at the bottom of the whole system
 *but also* at the top of a StaffGroup inside the system.
 This is more complicated since it is a combination of both a & b.
 So the possibility to use "doubleMetronomeMarks" within the Score
 context should let the possibility _not to use it_ within the
 StaffGroup.  I have no idea how to make that possible.
 By defining "doubleMetronomeMarks" as a property of the grob
 MetronomeMark?


>  (3) MMs should be baseline-alignable across any given system;

I did not go "that far" in my expectations...


>  (4) These rules need to be followed regardless of which staves appear
> or disappear (cf \RemoveEmptyStaffContext).

Of course I agree.
But didn't "Staff_collecting_engraver" already take care of that?
(or should be supposed to)


> In the short term, I'm considering creating a Tempo context, which
> only prints out tempo indications (akin to the TimeSig context of
> yore).  This context could then be placed in the \score wherever one
> needs it, solving (1), (2), and (4); since the context would be
> independent of any other contexts, (3) is automagically solved.
> But I want this to be easy to implement, so I either want the Tempo
> context to automagically ignore everything except MetronomeMark grobs,
> or I need to build a function/macro to strip out everything except
> MetronomeMark grobs.

I do not like this idea.
As Carl said, that would _constrain_ the user to have a separate music
expression to pass to the Tempo context... and I hate that!
We do not have a separate context for RehearsalMarks.
We have a separate "Dynamics" context for Piano centered dynamics
and I hate that...

That's not how it is supposed to work (IMO).
I would 100 times prefer to have it handled by a simple property change.

  \override DynamicLineSpanner #'centered-between-staves = ##t

same for Metronome(+Rehearsal)Mark :

  \override MetronomeMark #'baseline-align = ##t

but _keeping them in the normal (Staff) context_!


> Q#2: In the long term, would the short term solution still be the best,
> or should Lilypond Do The Right Thing™ in some other way that doesn't
> require a separate context?

I definitely agree.
Of course your Q#1 "separate context" solution could maybe be more
easily implemented, but from a user point of view this is awkward,
not intuitive and certainly unpleasant: that would constrain people to
separate the music into parts (notes, dynamics, indications, ...),
constrain them to use a \global variable and to play with spacer rests.

Of course you can "split" music into different variables if you want,
but I do not want this to become an "obligation".


We all want LilyPond to Do The Right Thing™.  ;-)

Cheers,
Xavier

--
Xavier Scheuer 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [Patch] 'transparent vs. 'whiteout

[Marc Hohl]

Carl Sorensen schrieb:

Marc,

The code looks great to me.  Please email me a patch (so it will have you as
the author) and I will push it.
  

Here it is.

Thank you,

Marc

Thanks,

Carl


On 6/19/10 3:11 AM, "Marc Hohl"  wrote:

  

Hello all,

after some discussions on the frog list I created a patch improving the
use of the 'transparent property. As Neil suggested, an invisible grob
should have no whiteout, and this is what the patch does.

After grepping through the code, I don't think that this will influence the
overall use of 'whiteout and 'transparent, but it will make things much
easier
for tablature.

Marc

http://codereview.appspot.com/1681043


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel




  


>From 486a73e3ac0bd30a3585210e7e6a8593702141e8 Mon Sep 17 00:00:00 2001
From: Marc Hohl 
Date: Sat, 19 Jun 2010 11:02:24 +0200
Subject: [PATCH] Dependency of 'transparent and 'whiteout

If a grob is invisible, the 'whiteout property should not
be taken into account. This will simplify the tablature
handling and doesn't affect the rest.
---
 lily/grob.cc   |7 +--
 scm/define-grob-properties.scm |3 ++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/lily/grob.cc b/lily/grob.cc
index 2680f55..5d48f27 100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -123,7 +123,9 @@ Grob::get_print_stencil () const
   if (Stencil *m = unsmob_stencil (stil))
 {
   retval = *m;
-  if (to_boolean (get_property ("transparent")))
+  bool grob_transparent = to_boolean (get_property ("transparent"));
+  
+  if (grob_transparent)
retval = Stencil (m->extent_box (), SCM_EOL);
   else
{
@@ -156,7 +158,8 @@ Grob::get_print_stencil () const
}
 
   /* process whiteout */
-  if (to_boolean (get_property ("whiteout")))
+  /* a grob has to be visible, otherwise the whiteout property has no 
effect */
+  if (!grob_transparent && to_boolean (get_property ("whiteout")))
 {
   /* Call the scheme procedure stencil-whiteout in scm/stencils.scm */
   /* to add a round-filled-box stencil to the stencil list */
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index cfa8726..1ab4562 100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -846,7 +846,8 @@ one below this grob.")
  (when ,ly:moment? "Global time step associated with this column
 happen?")
  (whiteout ,boolean? "If true, the grob is printed over a white
-background to white-out underlying material.  Usually #f by default.")
+background to white-out underlying material, if the grob is visible.
+ Usually #f by default.")
  (width ,ly:dimension? "The width of a grob measured in staff
 space.")
  (word-space ,ly:dimension? "Space to insert between words in
-- 
1.5.4.3

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to develop Emacs mode?

[Nicolas Sceaux]

Le 19 juin 2010 à 16:15, David Kastrup a écrit :

> Nicolas Sceaux  writes:
> 
>> Le 19 juin 2010 à 14:23, David Kastrup a écrit :
>> 
>>> It would appear that you work on MacOSX or so.  Can you check whether
>>> some variation of the Midi test code using make-serial-process I posted
>>> recently could be made to work on your setup?  If it did, this would be
>>> much preferable to having to use external applications like rumor.
>> 
>> My machine does not have a serial port,
> 
> Neither has mine.  I just use make-serial-process's ability to actually
> work with any character device for attaching it to a midi port.  The
> actual Midi connection happens to be a USB Midi converter.

Ah OK, good to know.
I'm trying to use a virtual midi keyboard and the make-serial-process
function.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to develop Emacs mode?

[David Kastrup]

Nicolas Sceaux  writes:

> Le 19 juin 2010 à 16:15, David Kastrup a écrit :
>
>> Nicolas Sceaux  writes:
>> 
>>> Le 19 juin 2010 à 14:23, David Kastrup a écrit :
>>> 
 It would appear that you work on MacOSX or so.  Can you check whether
 some variation of the Midi test code using make-serial-process I posted
 recently could be made to work on your setup?  If it did, this would be
 much preferable to having to use external applications like rumor.
>>> 
>>> My machine does not have a serial port,
>> 
>> Neither has mine.  I just use make-serial-process's ability to actually
>> work with any character device for attaching it to a midi port.  The
>> actual Midi connection happens to be a USB Midi converter.
>
> Ah OK, good to know.
> I'm trying to use a virtual midi keyboard and the make-serial-process
> function.

Well, here is what works for me (":speed nil" is necessary to trick
make-serial-process into not trying to set a speed on the "serial" port)
for letting Emacs display data arriving on the Midi interface.  On
GNU/Linux.  But it is not unlikely that a character device like that
would be available under OS/X as well.

(make-serial-process :port "/dev/midi1" :speed nil
  :buffer "*lily-midi*"
  :coding 'binary
  :noquery t
  :filter (lambda (process string)
 (message (mapconcat (lambda(x) (format "%02x" x)) string " "


-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: bounties

[Valentin Villenave]

On Sat, Jun 19, 2010 at 3:02 AM, Kieren MacMillan
 wrote:
> An excellent idea... and I don't only say that because I'd already set 
> something like that in motion.  ;)
> I've contacted my alma mater and have initiated just such a conversation -- 
> will report back as things progress.

Ditto here. I have contacted dozens of French universities, music
schools, government-funded music structures and whatnot. Everytime I
got an answer, the answer was: "Fuck off, we already have Finale".

Or something like that.

Cheers,
Valentin

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 100+ warnings (issue1724041)

[papuska]

  Thank you Patrick, I have reinstalled imagemagick also, and now it was
finally working.
  It took me some time to get familiar with vmware, Linux (again),
Eclipse CDT, GIT, Lily etc :).
Thanks for the patience :).

  I've separated the warnings patch
(http://codereview.appspot.com/1724041/show). Since it's my first patch
here, I would kindly ask, that someone checks the regressions again.
I hope it's OK now :), please tell me, if it ain't :).

Thanks,
  Lőrinc

http://codereview.appspot.com/1724041/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Woodwind diagrams (issue1425041)

[Mike Solomon]

Thank you Patrick!
All of your comments have been incorporated into a new patch, which draws
the svgs a-ok (see attached).

~Mike


On 6/19/10 12:42 AM, "pnor...@gmail.com"  wrote:

> Hi Mike,
> 
> This is very impressive.  Thanks for your work on this.  I just have a
> few comments for you about the SVG-related code.
> 
> Thanks,
> Patrick
> 
> 
> http://codereview.appspot.com/1425041/diff/12001/13007
> File scm/lily-library.scm (right):
> 
> http://codereview.appspot.com/1425041/diff/12001/13007#newcode583
> scm/lily-library.scm:583:
> If you want to use these procedures in output-svg.scm, they all need to
> be `define-public'-ified.  Like so:
> 
> (define-public PI (* 4 (atan 1)))
> 
> etc.
> 
> http://codereview.appspot.com/1425041/diff/12001/13010
> File scm/output-svg.scm (right):
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode352
> scm/output-svg.scm:352: (define (partial-ellipse x-radius y-radius
> start-angle end-angle thick connect fill)
> Move the definition of `new-start-angle' to here so that this code will
> compile (`new-start-angle' is used in `make-ellipse-radius')
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode362
> scm/output-svg.scm:362: (new-end-angle (* PI-OVER-180 (angle-0-360
> end-angle)))
> PI-OVER-180 and other procedures will work once you make the changes in
> lily-library.scm.
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode399
> scm/output-svg.scm:399: (if
> Please condense this block like so:
> 
> (if connect
>  (ly:format "L~4f,~4f"
>   (* start-radius (cos new-start-angle))
>   (- (* start-radius (sin new-start-angle
>  "")))
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode418
> scm/output-svg.scm:418: ;; Hopefully will be mitigated by ~4f below.
> Uh, how is this a security risk?  PS code is not interpreted by SVG
> agents, and here we are just dealing with simple numbers and strings
> that turn into SVG markup.
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode421
> scm/output-svg.scm:421: (string-concatenate
> I would condense this block too, to make it more readable:
> 
> (string-concatenate
>(map (lambda (x)
> (apply
>   (if (eq? (length x) 6)
>   (lambda (x1 x2 x3 x4 x5 x6)
> (ly:format "C~4f ~4f ~4f ~4f ~4f ~4f"
>(* x1 x-scale)
>(- (* x2 y-scale))
>(* x3 x-scale)
>(- (* x4 y-scale))
>(* x5 x-scale)
>(- (* x6 y-scale
>   (lambda (x1 x2)
> (ly:format "L~4f ~4f"
>(* x-scale x1)
>(- (* y-scale x2)
>   x))
> pointlist))
> 
> http://codereview.appspot.com/1425041/show
> 



svgtest.svg
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] Add \path markup command, and use it for \eyeglasses.

[Patrick McCarty]

Hello,

This is a feature I've wanted to add to LilyPond for a while, and I've
posted a patch set on Rietveld:

http://codereview.appspot.com/1730044/show

Any comments are appreciated, especially regarding the syntactic
requirements of the new command.

Thanks,
Patrick

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Add \path markup command, and use it for \eyeglasses.

[Werner LEMBERG]

> This is a feature I've wanted to add to LilyPond for a while, and I've
> posted a patch set on Rietveld:
> 
> http://codereview.appspot.com/1730044/show
> 
> Any comments are appreciated, especially regarding the syntactic
> requirements of the new command.

Looks good to me.  It would be nice if I could say

  \path #0.25 #'miter #'square ##f #samplePath

instead of using numbers for the second and third parameter.  Is this
possible?


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Add \path markup command, and use it for \eyeglasses.

[David Kastrup]

Werner LEMBERG  writes:

>> This is a feature I've wanted to add to LilyPond for a while, and I've
>> posted a patch set on Rietveld:
>> 
>> http://codereview.appspot.com/1730044/show
>> 
>> Any comments are appreciated, especially regarding the syntactic
>> requirements of the new command.
>
> Looks good to me.  It would be nice if I could say
>
>   \path #0.25 #'miter #'square ##f #samplePath
>
> instead of using numbers for the second and third parameter.  Is this
> possible?

How about defining constants path:miter and path:square instead?  Then
\path does not need special code, and the command would just be

\path #0.25 #path:miter #path:square ...

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Add \path markup command, and use it for \eyeglasses.

[Werner LEMBERG]

>> Looks good to me.  It would be nice if I could say
>>
>>   \path #0.25 #'miter #'square ##f #samplePath
>>
>> instead of using numbers for the second and third parameter.  Is this
>> possible?
> 
> How about defining constants path:miter and path:square instead?  Then
> \path does not need special code, and the command would just be
> 
> \path #0.25 #path:miter #path:square ...

Hmm.  I don't like the ugly `path:' prefix.  Usually, we don't have
this in arguments to lilypond commands, AFAIK.  From a syntactical
point of view, I can't see an immediate benefit of saying

  #path:miter

instead of

  #'miter


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel