Hi,
2013/11/27 Noeck noeck.marb...@gmx.de:
Hi
Just a quick but honest thank you from my side to all of you for
improving the out-of-the-box quality, tweaking-possibilities (e.g.
\shape) and simplifications for users (e.g. the.dot.syntax instead of #')!
You're welcome! And i join the
Hi,
recently I wrote that LilyPond input files - being plain text - are a
quite natural choice for single-source or cross-media publishing.
However, I'm not so sure anymore that this is really true (yet).
When finishing a LilyPond score to publication quality there is quite a
lot of tweaking
Urs Liska m...@ursliska.de writes:
Hi,
recently I wrote that LilyPond input files - being plain text - are a
quite natural choice for single-source or cross-media publishing.
However, I'm not so sure anymore that this is really true (yet).
When finishing a LilyPond score to publication
David Kastrup writes:
Sure. For that reason, I consider much of the time spent on tweaking
and tweaking tools a waste of lifetime better spent on trying to get the
automatisms right. Of course, that option is harder and requires
different resources. But it only needs to be done once.
Yes,
Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
We used to have an experimental `tweak editor' that would store tweaks a
in a separate tweaks file. In some way it would be a nice intermediate
to put all manual tweaks in a separate file and merge them with the
actual source. It would be good to
Hello all,
I am used to this topic. And I made up my own tool, which is working for
me, but should be called experimental.
I always hesitate to post my github link, because its not well
formed/documented and a mixup of totally different things ...
but there is one engraver, which actually deals
2013/11/26 Urs Liska u...@openlilylib.org
A way to permanently separate music source from tweaks would be a good
thing IMO. Separating content from appearance.
If that would be possible one could switch a set of tweaks (i.e. different
target formats) together with the different layout style
On Tue, 2013-11-26 at 11:35 +0100, Urs Liska wrote:
Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
We used to have an experimental `tweak editor' that would store tweaks a
in a separate tweaks file. In some way it would be a nice intermediate
to put all manual tweaks in a separate file
Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
Sure. For that reason, I consider much of the time spent on tweaking
and tweaking tools a waste of lifetime better spent on trying to get the
automatisms right. Of course, that option is harder and requires
different resources. But it only
Am 26.11.2013 14:12, schrieb Jan-Peter Voigt:
Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
Sure. For that reason, I consider much of the time spent on tweaking
and tweaking tools a waste of lifetime better spent on trying to get the
automatisms right. Of course, that option is harder and
Hi all,
we should also work on good interfaces for
tweaking the engraving *and* on interfaces to separate content and
design. In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave
On 11/26/13 6:12 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote:
In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave it.
- I want to be able to say: Modify item x in measure n on moment
Am 26.11.2013 14:41, schrieb Carl Sorensen:
It's more complex than having a single file that can be correctly
processed by lilypond, but it's doable with today's tools.
Do you have actual experience how this setup behaves when you have to
update the content?
Having the branches like you do
Am 26.11.2013 14:28, schrieb Urs Liska:
In what way do you consider it experimental?
I don't like the current way of addressing the contexts. I still have to
first look in the created *.edition.log file, to see, under which path
the context is addressed. This is OK for me, but I don't know, how
Carl Sorensen c_soren...@byu.edu writes:
On 11/26/13 6:12 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote:
In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave it.
- I want to be able to
Am 26.11.2013 14:41, schrieb Carl Sorensen:
In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave it.
- I want to be able to say: Modify item x in measure n on moment m with
Am 26.11.2013 15:04, schrieb Jan-Peter Voigt:
and right docs sooon
I meant write docs soon ...
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Hi Jan-Peter (et al.),
Most times I was able to use (once) override or set, which are
supported. Also supported are break and pageBreak. But if one wants to
edit one notehead (or Accidental) of a chord, it seems not possible
right now. I probably will introduce an interface for that kind of
On 26/11/13 11:01, David Kastrup wrote:
Sure. For that reason, I consider much of the time spent on tweaking
and tweaking tools a waste of lifetime better spent on trying to get the
automatisms right. Of course, that option is harder and requires
different resources. But it only needs to be
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:
I think that you personally are quite right to focus your efforts on
automation, but it doesn't mean that the efforts to build friendly
tweaking tools are a waste of time or resources ill-spent.
The problem is not with the friendly
Hi Kieren,
On 26.11.2013 15:38, Kieren MacMillan wrote:
As someone who is experimenting with polymetric music (i.e., with non-aligned
bar lines), please consider — and try to handle gracefully — such situations.
(That is to say, “measure-moment-context” must be Voice-, or at least Staff-,
On 11/26/13 6:45 AM, Urs Liska u...@openlilylib.org wrote:
Am 26.11.2013 14:41, schrieb Carl Sorensen:
It's more complex than having a single file that can be correctly
processed by lilypond, but it's doable with today's tools.
Do you have actual experience how this setup behaves when you
Am 26.11.2013 17:16, schrieb Carl Sorensen:
On 11/26/13 6:45 AM, Urs Liska u...@openlilylib.org wrote:
Am 26.11.2013 14:41, schrieb Carl Sorensen:
It's more complex than having a single file that can be correctly
processed by lilypond, but it's doable with today's tools.
Do you have actual
Hi all,
The number we want to be talking about is maybe a tweak every few pages.
A friendly tweaking tool is still nice for that, but it's not as
important than when you are doing a hundred tweaks per page.
But if we are talking about a hundred tweaks per page, it is extremely
unlikely
Kieren MacMillan kieren_macmil...@sympatico.ca writes:
Hi all,
The number we want to be talking about is maybe a tweak every few pages.
A friendly tweaking tool is still nice for that, but it's not as
important than when you are doing a hundred tweaks per page.
But if we are talking about
2013/11/26 Urs Liska m...@ursliska.de:
When finishing a LilyPond score to publication quality there is quite a lot
of tweaking involved - as you can see from Janek's recent posts on
lilypondblog.org. And this tweaking makes the engraving very specific,
actually it's only valid for a specific
2013/11/26 Carl Sorensen c_soren...@byu.edu:
On 11/26/13 6:45 AM, Urs Liska u...@openlilylib.org wrote:
Am 26.11.2013 14:41, schrieb Carl Sorensen:
It's more complex than having a single file that can be correctly
processed by lilypond, but it's doable with today's tools.
Do you have actual
2013/11/26 Carl Sorensen c_soren...@byu.edu:
My complex versioning strategy (as Urs correctly called it) is to put
the music in a git repository, with a branch for content, and then a
separate branch for each edition. The branches for each edition are
maintained to be one commit away from the
2013/11/26 David Kastrup d...@gnu.org:
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:
I think that you personally are quite right to focus your efforts on
automation, but it doesn't mean that the efforts to build friendly
tweaking tools are a waste of time or resources
Am 26.11.2013 18:12, schrieb Janek Warchoł:
Bottom line: after \shaping 1000 slurs, i got really bored and
improved \shape. After using it for the next 500 slurs, i expect to
get really bored again and fix some issues in slur formatting that
will bother me the most - because i'll be_personally
Janek Warchoł janek.lilyp...@gmail.com writes:
2013/11/26 David Kastrup d...@gnu.org:
But if we are talking about a hundred tweaks per page, it is
extremely unlikely that those tweaks are _not_ dealing with
systematic problems, and dealing with systematic problems is
something that the
On 11/26/13 9:50 AM, Janek Warchoł janek.lilyp...@gmail.com wrote:
2013/11/26 Carl Sorensen c_soren...@byu.edu:
This isn't as big a problem as it could be because I don't get to the
tweaks until the content is reasonably settled.
I was thinking about such setup, too. But the problem that i
2013/11/26 David Kastrup d...@gnu.org:
Janek Warchoł janek.lilyp...@gmail.com writes:
2013/11/26 David Kastrup d...@gnu.org:
But if we are talking about a hundred tweaks per page, it is
extremely unlikely that those tweaks are _not_ dealing with
systematic problems, and dealing with
Hi
Just a quick but honest thank you from my side to all of you for
improving the out-of-the-box quality, tweaking-possibilities (e.g.
\shape) and simplifications for users (e.g. the.dot.syntax instead of #')!
I think, the blog posts show that there is still room for improvements
to the
34 matches
Mail list logo
