Wikipedia won't allow lilypond due to security and performance reasons
as far as I know.
I and other have already created quite useful mediawiki plugins.
Bert
Francisco Vila wrote:
2009/4/21 Helder Geovane Gomes de Lima :
Hi everybody!
I would like to know if there is any progress about t
Hi Jan,
On Thu, Apr 16, 2009 at 01:43:07PM +0200, Jan Nieuwenhuizen wrote:
>
> >* it should -C change directory to target/installer/...,
> > I see no reason for . to exist, be writable, much less
> > to be open()ed
> >* "my" tools/root/usr/bin/tar does not seem to do this,
> >
On 4/21/09 3:04 PM, "Neil Puttock" wrote:
> 2009/4/21 Carl D. Sorensen :
>
>> I haven't checked yet for beam subdividing (I will need to, I know), but for
>> autobeaming, the work is done in a scheme callback, where the context is
>> available.
>
> There is no callback, otherwise get_propert
2009/4/21 Helder Geovane Gomes de Lima :
> Hi everybody!
>
> I would like to know if there is any progress about this topic.
> How is it going? (is it going?)
Are you talking about
- the LilyPond article on Wikipedia
- the LilyPond plugin for mediawiki
There was an interesting project in http://
Hi Jan,
On Thu, Apr 16, 2009 at 01:49:52PM +0200, Jan Nieuwenhuizen wrote:
> Op woensdag 15-04-2009 om 00:51 uur [tijdzone -0700], schreef Patrick
> McCarty:
>
> > I am trying to build a mingw LilyPond installer, but I am running into
> > a problem at the tools::bison configure stage.
> >
> > It
Hi everybody!
I would like to know if there is any progress about this topic.
How is it going? (is it going?)
Thanks!
Helder
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/4/21 Robert Memering :
> I have come across several cases with non-melismatic ligatures in
> renaissance polyphony.
> Indeed, I am afraid that changing the default behaviour would break several
> of my scores.
This wouldn't be an issue since it would be implemented in the same
way as current
2009/4/21 Carl D. Sorensen :
> I haven't checked yet for beam subdividing (I will need to, I know), but for
> autobeaming, the work is done in a scheme callback, where the context is
> available.
There is no callback, otherwise get_property ("autoBeamCheck") would
automatically return #t or #f; i
On 4/18/09 5:54 PM, "Neil Puttock" wrote:
> 2009/4/15 Carl D. Sorensen :
>
>> So why can't we define an AutoBeamPlaceHolder grob description (defined in
>> scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
>> scm/define-grob-interfaces.scm)? It would have no engrave
John Mandereau a écrit :
People should never be bored by manually editing snippets in input/new
to write them in input/lsr, as this can be handled automatically by
makelsr, but there are some formatting requirements for stuff in
input/new that are not necessary for regression tests, e.g. taggin
Michael Käppler schrieb:
Hi all,
I recently noticed that ligatures are not automatically noticed as a
melismatic section. That means, I always have to
use the syntax: \[ bla \melisma bla \melismaEnd \]
However, I would consider ligatures to be melismatic in >any< case.
What's your point?
Reg
11 matches
Mail list logo