Kieren MacMillan writes:
> Hi Mike (et al.),
>
>>> What would be involved in developing a feature to add notes or
>>> tweaks at an arbitrary moment within a music expression?
>>> music = \addAt (4 3/8) \global \once \override
>>> RehearsalMark.extra-offset #’(-1 . 0)
>
>> we’re about a half-day’s
On 2014/01/14 14:30:45, dak wrote:
https://codereview.appspot.com/51230043/diff/20001/ly/satb.ly#newcode75
ly/satb.ly:75: #(define-once Key *unspecified*)
I don't see that using some Scheme interface rather than providing
that facility
on the LilyPond level makes a lot of sense. For one thin
On Tue, Jan 14, 2014 at 11:51 AM, Urs Liska wrote:
>
>
> As you can see I have created a flowchart to visualize the relation
> between the different parts of the editing cycle.
>
> If it were simple the two PNG files I knew that I would have to add them
> to lilypond-extra and open a pull request
Urs Liska wrote
> a) in what form should I provide such an image that it can be translated
> and modified in the future?
Since your image is simply boxes with text and arrows connecting them, one
possibility might be to do it with html and css rather than making it an
image. The styling and layo
Kieren MacMillan writes:
> Hi all,
>
>> So "a half-day's work" is more like the estimate for
>> every single further fix making the timing simulation work closer to
>> what iteration would do anyway.
>
> Well, then… tell me the real cost, and I’ll see what I can do to
> [help] sponsor it.
Well,
Am 15.01.2014 16:13, schrieb Paul Morris:
Urs Liska wrote
a) in what form should I provide such an image that it can be translated
and modified in the future?
Since your image is simply boxes with text and arrows connecting them, one
possibility might be to do it with html and css rather than
Am 15.01.2014 16:13, schrieb David Kastrup:
then I need to prepare two
papers/talk proposals about LilyPond till the end of this week.
Are you talking about LAC2014?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman
Urs Liska writes:
> Am 15.01.2014 16:13, schrieb David Kastrup:
>> then I need to prepare two
>> papers/talk proposals about LilyPond till the end of this week.
>
> Are you talking about LAC2014?
No. http://chemnitzer.linux-tage.de>.
--
David Kastrup
_
Am 15.01.2014 16:21, schrieb David Kastrup:
Urs Liska writes:
Am 15.01.2014 16:13, schrieb David Kastrup:
then I need to prepare two
papers/talk proposals about LilyPond till the end of this week.
Are you talking about LAC2014?
No. http://chemnitzer.linux-tage.de>.
OK. Otherwise I'd h
Hi all,
> So "a half-day's work" is more like the estimate for
> every single further fix making the timing simulation work closer to
> what iteration would do anyway.
Well, then… tell me the real cost, and I’ll see what I can do to [help] sponsor
it.
There is *NOTHING* I can think of which woul
Another possibility would be to do it as a LilyPond snippet using markup
commands. That would keep it as close as possible to the usual LilyPond
docs/website process.
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Pre-review-questions-about-image-s-and-translatio
> For better or worse, I am currently focusing on speeding up "git
> blame" which is braking down lots of people.
Excellent! If you want a test case from the dark side, try
http://repo.or.cz/w/wortliste.git
For historical reasons, the `wortliste' is a single, large file
instead of smaller on
On Wed, Jan 15, 2014 at 10:15 AM, Urs Liska wrote:
> Am 15.01.2014 16:13, schrieb Paul Morris:
>
> Urs Liska wrote
>>
>>> a) in what form should I provide such an image that it can be translated
>>> and modified in the future?
>>>
>>
>> Since your image is simply boxes with text and arrows conne
Werner LEMBERG writes:
>> For better or worse, I am currently focusing on speeding up "git
>> blame" which is braking down lots of people.
>
> Excellent! If you want a test case from the dark side, try
>
> http://repo.or.cz/w/wortliste.git
>
> For historical reasons, the `wortliste' is a singl
Hi Kieren, James and all,
I extracted my edition-engraver from lalily. The example compiles here
with 2.18.
You can try this and comment ... I will add more comments to the code,
if this is of interest ;)
The compilation creates a file example.edition.log containing all
edition-engraver paths.
I
Carl Peterson wrote
> Maybe not texidoc-wise, but it's something I thought about on its own
> merits. I'm personally not crazy about is as it would basically result in
> us creating a very specialized set of CSS parameters for a very specific
> thing that could be changed and completely removed or
Am 15.01.2014 18:32, schrieb Paul Morris:
Those are good points. Using inline styles would be a way to address these
issues, while raising others... but maybe it wouldn't work with texidoc
anyway.
I gave a markup version a try:
That's great! Thanks.
I will play around with this and integrate
Am 15.01.2014 18:32, schrieb Paul Morris:
Carl Peterson wrote
Maybe not texidoc-wise, but it's something I thought about on its own
merits. I'm personally not crazy about is as it would basically result in
us creating a very specialized set of CSS parameters for a very specific
thing that could
How much sense would it make for there to be a separate \mark-style command
that functioned identically but didn't mess with the counter?
On Tue, Jan 14, 2014 at 8:30 AM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:
> Hi Werner,
>
> > I suggest that such a command allows for a third,
Hi Alex,
> How much sense would it make for there to be a separate \mark-style command
> that functioned identically but didn't mess with the counter?
Meh… I don’t really like the original suggestion (of a RehearsalMark-relative
\addAt parameter), so it makes little sense to me.
Cheers,
Kieren
Hi Jan-Peter,
> I extracted my edition-engraver from lalily.
This seems so magical as to be almost unbelievable. =)
1. What — if any — drawbacks are there?
2. Why is this not exactly (or even a superset of) the \addAt feature I
requested?
Thanks!
Kieren.
__
>> How much sense would it make for there to be a separate \mark-style
>> command that functioned identically but didn't mess with the
>> counter?
I'm all for it!
> Meh… I don’t really like the original suggestion (of a
> RehearsalMark-relative \addAt parameter), so it makes little sense
> to me
Alex Loomis writes:
> How much sense would it make for there to be a separate \mark-style command
> that functioned identically but didn't mess with the counter?
What do you mean? Neither \mark #4 nor \mark "G" mess with the counter.
--
David Kastrup
_
Am 16.01.2014 06:35, schrieb David Kastrup:
Alex Loomis writes:
How much sense would it make for there to be a separate \mark-style command
that functioned identically but didn't mess with the counter?
What do you mean? Neither \mark #4 nor \mark "G" mess with the counter.
Perhaps some ki
https://codereview.appspot.com/51460043/diff/1/Documentation/web/introduction.itexi
File Documentation/web/introduction.itexi (right):
https://codereview.appspot.com/51460043/diff/1/Documentation/web/introduction.itexi#newcode1138
Documentation/web/introduction.itexi:1138: before they come up!
O
On Wed, Jan 15, 2014 at 08:33:37AM -0500, Carl Peterson wrote:
>My first instinct is to prepare an SVG file that could be processed with
>inkscape or another program as part of the make process.
That is not do-able for the website due to our hosting&build
situation. I've commented on this
26 matches
Mail list logo
