On 03/05/15 16:53, Phil Holmes wrote:
I'd be willing to start a draft requirements for issue handling document
tomorrow, if no-one else is desperate.
That'd be great, though it'd be even better if there could be clear requirements
beyond merely those of issue handling -- code hosting, code
On 10/04/15 09:34, Werner LEMBERG wrote:
So the question is whether Launchpad has a usable API, right? Joseph,
do you know more?c
Just to follow up on this, I exchanged a few messages on Reddit with Colin
Watson (who's leading the git-support effort) following this announcement:
On 10/04/15 09:34, Werner LEMBERG wrote:
While I don't like bzr, the launchpad interface for reporting bugs and
the like looks OK to me. So yes, this is a possible solution.
I think this has already been mentioned but just to chip in that it
isn't just about reviewing patches, patches have to
On 13/03/15 12:51, David Kastrup wrote:
GitLab (like GitHub) does not run on free software. They have some
community version of their software freely available at least.
Gitorious was eating its own dog food with regard to running on their
free software version, but they have just been acquired
On 09/01/14 12:20, David Kastrup wrote:
Another problem is that LilyPond has a usage philosophy and workflow
that strongly penalizes manual tweaks. Graphically/manually oriented
workflows detract from the importance of getting good default
typesetting.
I'm not sure that's necessarily the
On 09/01/14 21:05, David Kastrup wrote:
That must be the reason why the typical Word document features the
consistent use of document styles for arriving at typographically
superior results.
I'm not sure that I feel happy about your benchmark for comparison. I think
Lilypond's user base is a
On 03/12/13 13:16, David Kastrup wrote:
LilyPond's rendition of the slurs is actually reasonable readable.
However, the measures take probably 40% more width.
That's not necessarily a bad thing. My impression is that older scores are
often more horizontally (and vertically) compact in order
On 03/12/13 14:25, David Nalesnik wrote:
The problem is that the position of the tuplet number is tied to the placement
of the tuplet bracket, whether it is drawn or not.
I would argue that probably here the _real_ problem is that the tuplet bracket
is designed to always place itself outside
On 23/10/13 18:22, David Kastrup wrote:
Ubuntu 13.10 is delivered with LilyPond 2.16.2 built using a Metapost
version of 1.802. Consequently, all the included fonts look like crap.
The fix for this should now be released:
On 09/11/13 11:10, Janek Warchoł wrote:
Hmm. Good question. Maybe it could be attached to NoteHeads, not NoteColumns?
(As i understand it, the problem with attachments results from the
fact that slurs are attached to notecolumns (the bound of the slur
spanner is the NoteColumn), and at
On 07/11/13 22:21, Keith OHara wrote:
The use of two alterations, natural-up and sharp-down, for the same pitch
where the note-head is on the same staff-position is problematic to read.
I would hope that composers choose one glyph and use it consistently
within a piece.
Your notational
On 07/11/13 07:26, Keith OHara wrote:
The arrow notation also gives two options for the half-flat: natural-down-
arrow and flat-up-arrow. If someone uses both options for the half-flat in
the same piece, LilyPond can keep track of the choice by using a tuning
system that has them at slightly
Hello all,
It looks like there's a blocking factor in releasing the fixed Lilypond 2.16.2
on Ubuntu 13.10: the PowerPC build of the updated package is failing.
Here's the build log:
On 03/11/13 10:09, Mike Solomon wrote:
Looks like some files in flower don't play nice with the most recent version of
the standard library bundled with Xcode…
Any ideas for how to proceed?
If I understand right (I'm not a Mac user), latest Xcode has clang as default
compiler, and symlinks
On 03/11/13 10:37, David Kastrup wrote:
We committed a few Clang-related fixes in the past, I think mostly due
to Graham's insistence/testing, but I think at some point of time the
compile with Clang ambition just faded.
I just tried a clang-based build on my Ubuntu 13.10 system, just to see
On 03/11/13 11:00, Mike Solomon wrote:
That’s fine, I’ll download gcc.
From what I understand from friends who've experienced the same, you'll have to
manually remove/rewrite some of the symlinks.
Just to check -- before you rework everything -- did you manually re-run the
configure script
On 03/11/13 11:20, Hans Aberg wrote:
FYI, some Extended Helmholtz-Ellis JI” accidentals [1-2], in fact designed
quite recently, but a nice input. There is also a Unicode font at [3]. Notation also
mentioned at [4].
The arrow accidentals that LilyPond has, are used for syntonic comma 81/81
On 03/11/13 11:18, Mike Solomon wrote:
Yeah, the output is fine (clean bill of health, all systems go). I had to
specifically set CPPFLAGS to deal w/ some homebrew issues, but otherwise
nothing out of the ordinary.
Ahh, OK. That's odd; OK, I accept that the clang you have has been a little
On 03/11/13 11:42, Joseph Rushton Wakeling wrote:
For Lilypond in particular, the problem of supporting microtonal notation is
less about symbols per se and more about the underlying representation of pitch,
and how that relates both to accidentals and transposition.
Specifically in relation
On 03/11/13 12:33, Mike Solomon wrote:
[ ... snip ... ]
…these fonts are always a pain, but I usually figure out some way to cheat and
get them in there. But that shouldn’t have anything to do with the compiler.
Well, what's odd is that your ./configure script says that it finds gcc:
On 03/11/13 12:34, Hans Aberg wrote:
I know how to do it from the theoretical point of view, but somebody who knows
the internals of LilyPond must do it.
Of course. I'm just raising it as pertinent to the discussion. :-)
___
lilypond-devel
On 03/11/13 13:36, Mike Solomon wrote:
Doesn’t work, but all the files in flower compile fine with gcc, so I’m a happy
camper.
Apple’s home cooked clang is not free software, so there’s no reason to expect
free software to compile with it. I don’t mind giving up on it.
It's difficult to see
On 03/11/13 17:55, Hans Aberg wrote:
As a preparation, LilyPond might get intervals: it is going to be too
complicated to write out names for all pitch combinations.
A pitch is defined by a written pitch plus a sequence of intervals added to it.
Accidentals are a special case: intervals not
On 03/11/13 13:53, David Kastrup wrote:
We've been fingerpointing back and forth for years over this. Without
an actual user/musician like Hans at least teaming up with a programmer,
nothing will happen.
It's not meant to be fingerpointing -- I'm not blaming anyone for development
not moving
Hi all,
I'm just checking the updated Lilypond packages in Ubuntu saucy-proposed (the
ones that have the fix for the mpost bug) and I'm finding something odd: I
installed the PDF docs to check the fonts, but I can't find the actual PDF files
anywhere in /usr/share/doc.
Where are they
On 02/11/13 11:13, Joseph Rushton Wakeling wrote:
I'm just checking the updated Lilypond packages in Ubuntu saucy-proposed (the
ones that have the fix for the mpost bug) and I'm finding something odd: I
installed the PDF docs to check the fonts, but I can't find the actual PDF files
anywhere
On 01/11/13 16:29, Joseph Rushton Wakeling wrote:
There's now an updated texlive-binaries package in the saucy-proposed
repository, which can be used to test Lilypond builds:
https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/1243777/comments/11
The saucy-proposed repository now also has
On 02/11/13 15:12, Mike Solomon wrote:
Not sure what a git formatted patch is…I can, however, download the Rietveld
patch and send it to you if you want.
Git can extract text patch files from your version history, which can then be
sent by email. It's a simpler way of getting patches
On 25/10/13 13:45, Joseph Rushton Wakeling wrote:
Just FYI -- I've had a response from someone at Canonical who has asked me to
check a couple of things for them. Will update as/when I have more info.
There's now an updated texlive-binaries package in the saucy-proposed
repository, which can
Hello all,
The building of the various manuals takes quite a long time, but the build
process itself is silent so it's not easy to tell if they're actually
progressing or have somehow hung.
e.g. currently I'm just seeing:
LILYPOND_VERSION=2.17.29 /usr/bin/python -tt
On 25/10/13 19:31, Colin Campbell wrote:
FWIW, after installing Ubuntu 13.10 and seeing my ../configure choke on the
mpost version, I followede Werner Lemberg's suggestion from here:
http://article.gmane.org/gmane.comp.gnu.lilypond.devel/55828/match=mpost+broken
and all seems to be well. At
On 23/10/13 18:22, David Kastrup wrote:
This can seriously affect LilyPond's reputation. Anybody putting
together a comparison of various typesetting programs under GNU/Linux
will more likely be using this version than any other.
I don't know about other glyphs, but for what it's worth, the
On 25/10/13 11:36, David Kastrup wrote:
More like out-of-stylized. At any rate, incomplete flags actually
impede the readability more than once per line.
Again, if it makes any difference -- remember that this is a release with only
6-month max lifecycle, and that non-LTS (long-term-support)
On 25/10/13 12:09, David Kastrup wrote:
Who knows? If they go with TeXlive2013 as released for lack of a
compelling reason...
This is the version they have in the current development repositories:
https://launchpad.net/ubuntu/+source/texlive-bin/2013.20130729.30972-2
That's the fixed version
On 23/10/13 18:22, David Kastrup wrote:
Ubuntu 13.10 is delivered with LilyPond 2.16.2 built using a Metapost
version of 1.802. Consequently, all the included fonts look like crap.
Just FYI -- I've had a response from someone at Canonical who has asked me to
check a couple of things for
On 23/10/13 18:22, David Kastrup wrote:
Of course, this was sort of predictable. Would we have been in time if
we had immediately created a backport of the configure patch and named
the result 2.16.3?
I think it would depend on when you got it out by. As far as I can tell Ubuntu
just
On 24/10/13 17:24, David Kastrup wrote:
But they take the source package and compile themselves.
I think it likely that's an automated process.
Debian has already taken a fixed Metapost long ago, but Ubuntu has not
updated the TeXlive binaries in spite of me reporting the problem.
When did
On 21/10/13 07:58, Werner LEMBERG wrote:
I don't see a major simplification for the maintainer. The most
important action IMHO for contributing a patch is to rebase, ensuring
that the patch compiles with master. As far as I can see, github's
ticketing system doesn't allow to simply update the
On 21/10/13 09:09, Werner LEMBERG wrote:
Good to know, thanks. [I assume that `overwrite' still somehow
retains the previously version for reference, right?]
In the short term I think so (you'll see stuff in the comment history like
so-and-so commented on an outdated diff). In the long run
A couple of messages accidentally went off-list, forwarding them back here with
Werner's agreement :-)
On 21/10/13 08:02, Werner LEMBERG wrote:
The other advantage is that the merge commit is authored by the
person with master commit access who approves the merge request.
So, you have in
On 21/10/13 10:01, Trevor Daniels wrote:
The vast majority of my contributions are single-commit, and I
suspect most other contributions are the same. They are easy
to manage and generate a clean history with merge commits
appearing only when they are appropriate. Our git repository was
not
On 21/10/13 11:11, David Kastrup wrote:
Now it's rather hard to do a proper balance of the merits: basically we
are not aiming for a I could discipline myself into using xxx verdict
but rather for this will definitely make things quite easier for me in
the long run for a majority of existing and
On 21/10/13 14:25, Carl Sorensen wrote:
And based on Joseph's comments, it appears that I may be misusing GitLab a
little bit -- we've not been using good descriptions of the merge requests
(in fact, we may have not been using *any* descriptions of the merge
requests) so the merge commits only
On 21/10/13 14:30, Carl Sorensen wrote:
In our current workflow, once I submit a patch, it's a fixed submission.
I have to resubmit a different patch in order to change it.
In the gitlab workflow, when I submit a merge request, it's a dynamic
thing. Any time I push my merge-request branch to
On 20/10/13 11:15, James wrote:
Yes, although I don't want to be considered arrogant that it should only be
'acceptable to me'; but when the last Patch-nanny decided he was going 'spend
more time with his family' (so to speak speaking) and wanted to pass on the role
to someone else, the silence
On 21/10/13 04:00, Carl Sorensen wrote:
I have to say that I much prefer the Lilypond method for handling tasks
and reviews to the Gitlab method.
Can you describe in more detail what it is that you like about how Lilypond does
things, and how that is missing (or inferior) in GitLab?
On 21/10/13 06:13, Carl Sorensen wrote:
Even though it can be a pain to rebase commits, when it's done on the
current Lilypond process I feel like the commit messages are much better
than the ones that show up by default on Gitlab (merging branch xyz).
I'll test this out on GitLab just to see
On 21/10/13 07:41, Werner LEMBERG wrote:
This latter thing bothered me too initially (with GitHub) as I was
used to just pulling from the main repo to my local machine and
submitting patches via email; but I quickly realized that it was
actually sensible, and that those user repos are just
On 19/10/13 10:16, James wrote:
The point is that when I am managing 15 patch reviews I don't (won't) read the
email thread [1] I look at tracker, see what has been said, I click on Rietveld
see what has been said; it's all there in front of me, no extra windows to click
or open, one single
On 16/10/13 00:11, Janek Warchoł wrote:
I need at least 2 people who'd like to experiment with me - doing this
alone doesn't make sense. Colin, Joe - are you still interested?
Anyone else?
Yup, still in. :-)
___
lilypond-devel mailing list
Hello all,
I'm trying to build Lilypond from git-HEAD source for the first time in a while
and running into some curiosities from the ./configure script. This is on
Ubuntu 13.10.
First of all: ./configure requests a number of build dependencies that are not
listed on the pages here:
On 05/10/13 17:24, David Kastrup wrote:
That's not a workaround since your fonts would all be broken. Maybe
install TeXlive2013 to a local tree and update to the newest version
using tlmgr?
Currently trying to get it to set up a local texmf tree -- running any tlmgr
command, e.g. tlmgr
On 05/10/13 19:39, David Kastrup wrote:
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:
Unfortunately, nobody seems to be interested in
URL:https://bugs.launchpad.net/ubuntu/+source/texlive-bin/+bug/1220653
Thanks ever so much for looking into the problem in this depth.
In my
On 05/10/13 20:08, Joseph Rushton Wakeling wrote:
In my experience it can help if more than one person reports the bug as
affecting them (I've just done so). So, fingers crossed. By the look of it
though, they just copy over from Debian rather than having any dedicated TeXlive
maintainers
On 05/10/13 19:01, David Kastrup wrote:
Maybe you can use tlmgr for updating your Metapost.
Well, you saw the error I encountered when trying to use tlmgr to do that.
(Maybe I'm just misunderstanding how it works, I've never used it before.)
No idea. Or complain to Ubuntu that they still
On 26/09/13 18:38, David Kastrup wrote:
You commented on the issue where this patch originated as late as July:
URL:http://code.google.com/p/lilypond/issues/detail?id=1278#c7. So
it's hard to argue that it was not discoverable to you.
This July I got an email update from the issue, and
On 27/09/13 03:44, Graham Percival wrote:
On Thu, Sep 26, 2013 at 03:12:27PM +0200, Joseph Rushton Wakeling wrote:
This risks becoming another corrosive discussion,
Then WTF are you starting it?
Because I had hoped that what I said was sufficiently qualified not to create
bad feeling
On 26/09/13 12:26, David Kastrup wrote:
The dean is annoyed: Why can't you be like the mathematicians? They
just need pencils, paper, and a wastebasket and will work for years.
And the philosophers don't even need a wastebasket...
Not any more, either for mathematicians or philosophers ...
On 26/09/13 14:26, David Kastrup wrote:
So Graham organized the infrastructure where this would not easily
happen again in the same manner, and the Contributor's Guide reflects
it.
But we haven't exactly seen a flurry of patches from newcomers appearing
on the lists. Of course, part of the
On 26/09/13 13:56, Phil Holmes wrote:
As far as I'm concerned, Google Code could be changed. I find its restriction
on attachments annoying. However, a replacement would have to be able to import
_all_ the issues lodged there with all their detail and attachments, and provide
similar
On 26/09/13 11:48, Janek Warchoł wrote:
David is going to talk with Savannah people - that's great!
Other things that are worth looking at are:
- gitorious
- gerrit
- something else i've forgotten?
GitLab: http://gitlab.org/
Looks more feature-complete and user-friendly than Gitorious (it's
On 26/09/13 14:52, Phil Holmes wrote:
I thought I made this clear - I was repeating something Graham said to me on a
number of occasions. He would argue it was realistic, not pessimistic. You have
to be aware of the fact that, simply by working hard on a problem does not
guarantee that the
On 26/09/13 15:04, David Kastrup wrote:
How many substantial patches would you expect yourself to be
contributing in the wake of such a move per month to LilyPond?
Don't know. Most of my potential contributions to Lilypond are likely to be
documentation -- among other things I'd like to
On 26/09/13 15:23, David Kastrup wrote:
Well, you think that it's better to demoralize existing developers
rather than hypothetical would-be contributors nobody knows.
This is going to be a toxic direction of discussion if we pursue it, so I won't
respond, except to say that it is not my
On 26/09/13 16:37, Trevor Daniels wrote:
Almost exactly what I was about to reply, but Phil beat me to it! In fact I
think I remember helping you add the Contemporary music headings some
time ago, or was it someone else?
The section originates with me but I got diverted into trying to create
On 26/09/13 17:16, Phil Holmes wrote:
I think it's waiting for someone to propose how it could be represented in
LilyPond. If _someone_ were to do that, it might progress - it was only a few
months ago it was last looked at.
Unfortunately, it was someone putting forward a workaround which I'd
On 26/09/13 17:35, Joseph Rushton Wakeling wrote:
Unfortunately, it was someone putting forward a workaround which I'd already
proposed and found lacking, as it doesn't play nice with transposition :-(
There was actually a patch submitted which tweaked the internal pitch
representation
On 23/09/13 14:15, David Kastrup wrote:
GitHub's usage conditions are so aggressively proprietary and
disenfranchising that it's not suitable for our regular processes. They
reserve the right of shutting accounts and projects down if they don't
like their bandwidth usage or for any other
On 23/09/13 03:16, Graham Percival wrote:
The experience from the Grand Documentation Project is that only
25% of new doc contributors ended up being a net benefit. Having
an up-front hurdle, provided that it's well-explained, is a useful
way to weed out people who are likely to fall into the
On 22/09/13 17:21, Phil Holmes wrote:
IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly in a
Virtual Machine) provides git and git-cl. Git allows a developer to create a
patch with 2 commands: git commit and git format-patch. That can be uploaded to
Rietveld with a
On 23/09/13 08:59, David Kastrup wrote:
It may be that something like Gitorious would obsolete Gerrit (as well
as the Google issue tracker), but then we need to start somewhere.
Gitorious has no in-built issue tracker. I think the normal thing is to
integrate it with a project-specific Trac
On 23/09/13 14:15, David Kastrup wrote:
At any rate, I think the first thing we would likely want to experiment
with would just be Gerrit.
May be useful to you, if you haven't already read it:
http://feeding.cloud.geek.nz/posts/code-reviews-with-gerrit-and-gitorious/
On 24/09/13 13:58, David Kastrup wrote:
Well, the usage conditions prohibit mimicking them, but then I have my
doubts that this will stand before a court. So the worst that can
happen realistically is that they kick you out. Which they can for any
reason at all anyway.
Hmm, I'd like to see
On 24/09/13 14:09, David Kastrup wrote:
You _are_ aware that the _majority_ of current contributors is running
Windows?
Try setting up a native development environment for LilyPond on
Windows. Come back when you are done.
What is the reason for it being so difficult?
and the risk is that
On 24/09/13 14:14, Graham Percival wrote:
Umm, the whole point of the VM is to ensure that the contributor's
setup is *right*.
As far as I can see, the whole point of the VM is to get round the fact that the
range of environments you can use to hack on Lilypond is severely restricted.
I'm
On 24/09/13 14:22, Graham Percival wrote:
Suppose somebody sends you a bad patch that would take you 5
minutes to re-implement from scratch. Do you:
1) spend 30 minutes explaining how to fix the patch
2) tell them to go screw themselves
3) ignore the patch silently and give the person no
On 24/09/13 14:22, Graham Percival wrote:
I've done #1. I spent a WHOLE YEAR doing #1. It was an
experiment. I was absolutely committed to teaching people how to
do docs. However, #1 gives a net penalty of 25 minutes.
One thing to add. I completely get how frustrating and annoying it must
On 24/09/13 15:34, Phil Holmes wrote:
I imagine that one problem of using a VM is that it makes it much more
difficult/slow to run such local tests?
Not with current servers. GUB is built in a VM, much faster than most people
could do it natively.
Running on servers, sure. I was thinking
On 24/09/13 15:41, David Kastrup wrote:
What about Try it did you not understand? Windows does not just allow
you to say
sudo apt-get build-dep lilypond
Instead you have several dozens of dependencies you have to satisfy by
hand, and then the fun with registry entries and other stuff
On 24/09/13 15:45, David Kastrup wrote:
you is you. So start fixing it. You know better than everybody else
what is in need of fixing, so go ahead.
Every time I raise usability issues related to the contribution tools, I run
into this big wall of denial that there is actually a problem.
On 23/09/13 12:59, Graham Percival wrote:
Reviewing patches? Explaining why we reject a patch (I don't
think we can fairly reject a patch unless we explain why)? Those
are significant costs.
What are the most common reasons for doc patch rejection?
On 24/09/13 17:05, David Kastrup wrote:
No, you are not just asking. You are throwing diagnoses around and
proposing solutions that are known not to work.
I keep asking you questions because I want to correct my ideas and impressions
if they are wrong.
Still, I'm curious -- what is it
On 24/09/13 17:10, Phil Holmes wrote:
Poor syntax; poor explanation; unnecessary; failure to compile; failure to
follow standards.
OK. What are the typical patch-reviewer reactions to each of these?
___
lilypond-devel mailing list
On 24/09/13 18:05, James wrote:
The fact our documentation is (even if I do say so myself) very comprehensive,
is precisely because patches get reviewed and discussed before they are
incorporated (this wouldn't happen with a wiki). Things like users reporting
typos and simple changes often get
On 24/09/13 18:19, Janek Warchoł wrote:
Whatever is meant by those saying it, at the end of the day it comes across
as: Hey, we don't care about your usability issues, we don't care that it's
difficult and finnicky to contribute to us, we only care about solving that
problem if you solve it for
On 24/09/13 18:59, David Kastrup wrote:
How about not worrying about the tools then and just doing your
contribution any old way you prefer to work? We have procedures in
place for picking up from there.
I can give a detailed response here, but ... it's got a bit heated today. Shall
we pick
On 24/09/13 20:16, David Kastrup wrote:
Well, let's just say that our track record with I'll contribute once
everything is exactly like I want it, I could not expect to bother you
with my help before is not unlike that spelled out in Wilde's The
Devoted Friend
On 22/09/13 17:53, David Kastrup wrote:
Yup. So we are talking about creating untested patches here that
eventually travel into the usual testing pipeline we use.
The main GitHub-hosted project that I'm involved with has auto-testing set up
for pull requests, that's obviously integrated to
On 07/13/2013 02:11 PM, Federico Bruni wrote:
It was ignored from the very beginning (perhaps a kind of todo list):
Pretty much. At the actual time of writing there was some discussion of whether
or not to include info on interesting scores to look at, the general feeling was
against, but no
On 07/13/2013 07:52 PM, Mark Polesky wrote:
Personally, I'd prefer to remove all mention of Gardner
Read's book. Many of his recommendations are not good at
all, and I've found a fair number of them that are just
wrong.
Better to say that it's out of date. But its datedness is one reason
On 05/09/2013 02:52 PM, zepadovani.li...@gmail.com wrote:
just installed 2.17.17 and it seems that the new (and nice!) angled
hairpins are not compatible with the circled tip
I think this should be considered a bug, as the two notations are clearly
compatible.
On 03/26/2013 06:27 PM, David Kastrup wrote:
It might even make sense to try getting Steinberg on board. They have
just acquired the old Sibelius developers. Now the focus I see for
LilyPond itself is bringing it into line for operating it with a growing
corpus of public domain music. We'd
On 03/26/2013 11:52 AM, Han-Wen Nienhuys wrote:
Take in mind that EU research programmes come with an incredible
amount of burocracy and require both academic and industry partners,
the more the merrier. The projects that get funded are buzzword
compliant, but often nobody knows what they set
On 03/17/2013 06:47 PM, thomasmorle...@googlemail.com wrote:
And while above the staff dynamic brackets have the hook down.
As I said before, I'd have argued for that feature even in the absence of a
Ferneyhough example, as it makes musical/notational sense. But I think the
example settles it.
On 03/17/2013 05:28 PM, m...@mikesolomon.org wrote:
My suggestion was flairpin, which is infinitely cheesier and thus way cooler.
I know, but ... at the end of the day, less clear in meaning than either
ferneyhough-hairpin or flared-hairpin. Sad but IMO true. :-P
On 03/13/2013 12:22 AM, Janek Warchoł wrote:
this reminds me of an idea i had that would probably play nicely with this:
make it possible to manipulate hairpins' ends separately.
The point would be that you could specify a vertical offset for one
end and thus easily achieve a slanted hairpin
On 10/18/2012 09:38 AM, Han-Wen Nienhuys wrote:
The idea behind this is twofold: first, the GPL does not make sense
for a font.
That's not entirely true. Obviously it's not a good condition for use of a font
in a document, and you _can't_ copyright the _appearance_ of the font, but it
makes
On 10/13/2012 11:44 PM, David Kastrup wrote:
\once creates a one-time-step temporary change, \temporary an
unterminated temporary change which can be terminated element-wise with
\revert or, again using a converter, en bloc from the original overrides
with \undo.
Forgive me for coming into
On 10/09/2012 05:23 PM, Janek Warchoł wrote:
As for transposing clefs, i play guitar a bit myself, and i have once
typeset a piece using both G and G_8 clefs. Maybe it was a bad idea,
but for me it was perfectly fine.
Yes, definitely a bad idea. Use 8va. brackets instead when you want
On 10/10/2012 12:08 AM, Joseph Rushton Wakeling wrote:
Yes, definitely a bad idea. Use 8va. brackets instead when you want to
send everything up an octave like that. It was fine for _you_ because you wrote
it and knew what you wanted anyway, but it would have probably been confusing
1 - 100 of 161 matches
Mail list logo
