On 10/02/2012 07:20 AM, Keith OHara wrote:
There is also \endSpanners
{ \endSpanners b1\> }
What about where you want the hairpin to end on a specified dynamic (e.g.
decresc. to \p)?
Does this also work in the _middle_ of a piece, not just at the end of it?
On 10/02/2012 03:02 PM, Carlo Stemberger wrote:
Keith OHara oco.net> writes:
> There is also \endSpanners
>
> { \endSpanners b1\> }
Another question: how to get something like the attached image (\pp at the end)?
Note that this is a common notation in plenty of places other than at the en
On 10/06/2012 01:17 AM, The Doctor (Michael D) wrote:
I am using the gregorian to arrange Eastern Orthodox chant music. I am working
on music from the eight tones (which has a lot of 'recitatives') and *would
like* to be able to use tuplets to 'group' and indicate notes and thus syllables
that s
On 12/18/2012 05:16 PM, carltesta wrote:
I am working on typesetting another composer's music. In their music they
prefer to notate a 5:4 tuplet (5 sixteenth notes in the space of 4 sixteenth
notes) as 5:1 (5 sixteenths in the space of 1 pulse (quarter note). Is it
possible change Lilypond's MIDI
On 01/08/2013 09:35 PM, Urs Liska wrote:
During the development of a musical edition some others and me created the base
for a kind of LilyPond toolkit library. When the edition is finished we'll
change
that to be an open source project hosted on Github. This will consist of sets of
functionalit
On 01/10/2013 12:09 AM, Urs Liska wrote:
It was already discussed on this list: It was a silly idea to use copyrighted
material at all for this tutorial. It was just something I was working on at
that time, and I didn't really think about it ...
To be honest, I disagree. This is something that
On 01/10/2013 10:24 PM, Graham Percival wrote:
Unless you are planning this as a protest, I doubt that
deliberately setting out to infringe on copyright is a great
strategy. Are you really equipped to deal with a lawsuit from
music publishers -- especially since there's now a public record
of yo
On 01/10/2013 10:19 PM, Urs Liska wrote:
But there had been quite some discussion here whethere lilypond.org could link
to such a tutorial or not, and I tend to agree that an Open Source project
should have Open Documentation.
I agree, but I also think there's a difference between official docu
On 01/11/2013 01:24 AM, Urs Liska wrote:
Sorry, forgot to post where it is:
http://lilypond.ursliska.de/notensatz/lilypond-tutorials/tackle-complex-tasks/part-1-entering-the-music.html
Thanks for that. :-)
One note -- there was something I was wondering about looking at your example,
and the
On 01/11/2013 12:44 AM, Urs Liska wrote:
Bottom line: They didn't make very explicit statements, but they probably don't
really care about the case. From a pragmatical perspective this comes quite
close to 'fair use' (although it probably isn't).
Well, I am not a lawyer, but my impression is th
On 01/11/2013 07:52 PM, Urs Liska wrote:
I think it boils down to:
- can a GNU project link to (or promote in any other way) non-free
documentation?
- can I license a tutorial as free if it contains copyrighted material
(considered I got explicit permission to display the example on my web site
On 01/11/2013 10:10 PM, David Kastrup wrote:
Not as much "can" but rather "should", and the answer to that is "no".
"Should" needs to be tempered by a measure of common sense about whether doing
so serves the goals of the GNU project. Since the goal of a tutorial as
described here would be t
On 01/13/2013 12:09 AM, Antonio Gervasoni wrote:
However, I'm not a lawyer so I'm sure if this would work.
Well, there are surely organizations out there (Creative Commons, Software
Freedom Conservancy, ...) who can advise.
That said, as long as you secure the copyright holders' permission f
On 01/18/2013 03:06 PM, Yannick CHARLES wrote:
Regarding the typesetting, the quarter tone is written on the score, but not the
glissando. Is there a way to make it visible ?
Perhaps by tweaking minimum-length settings for the glissando? Most likely
(from my experience) it "appears" but is ju
On 01/27/2013 03:52 AM, Evan Driscoll wrote:
I was surprised to look on IMSLP not find a download of The Planets score that
is better than a somewhat mediocre scan.
Not sure which you're using, but the full-score PDF seems to my eye to be
superior to the individual-movement ones.
I'm not sur
On 01/28/2013 11:34 AM, Jeffrey Trevino wrote:
It should be pointed out that it's a common notational practice to hide the
unused non-center keys in fingering diagrams; this behavior is idiomatic.
Common, but not ubiquitous or standard, I'd say.
On Mon, Jan 28, 2013 at 2:27 AM, Eluze wrote:
p
On 01/28/2013 01:54 PM, Wim van Dommelen wrote:
Agreed, but for a series showing e.g. a scale it would be nice to have similar
diagrams, so I would like to control the behaviour myself.
Personally I prefer to see all the keys when it's a visual diagram.
That said, I think my preference _in gen
On 01/28/2013 11:54 PM, Wim van Dommelen wrote:
Me too, but having individual control satifies everyone.
Agreed. :-)
The big challenge will be to find some optimum which satifies the multitude of
brands and models. I've played on two brands, three models and these were all
different, I checke
On 01/29/2013 07:37 PM, Adam Spiers wrote:
I'm happy to announce the release of ly2video 0.3.0.
Nice! :-)
Re the Lilypond version requirement -- is this an "... or later" requirement or
is it really fixed to only work with 2.14.2? Might be worth clarifying in the
README.
_
On 01/29/2013 07:57 PM, Adam Spiers wrote:
I didn't notice that - I've certainly been using with later versions.
It actually uses convert-ly internally, but I'm not entirely sure why :)
One other thing -- re the python-midi dependency -- does this correspond to a
particular package in Debian/U
On 01/29/2013 09:12 PM, Joseph Rushton Wakeling wrote:
One other thing -- re the python-midi dependency -- does this correspond to a
particular package in Debian/Ubuntu that you know of? python-imaging and
python-pypdf were easy to find, it's not obvious what package (if any)
correspon
On 01/29/2013 09:50 PM, Wim van Dommelen wrote:
6. Lot's of models have a right-hand low-ees key (with the thumb), There is no
such key. Wishlist.
Not recent French models, in my experience, but I agree it's often found. The
trouble is its placement is not uniform.
The Selmer privilege has on
On 01/29/2013 10:46 PM, Wim van Dommelen wrote:
Uhh, never too old for a challenge, as I see it the register key is also
inherited, so it is one and the same definition. Can give it a try. What were
you thinking about?
Just a register key that looks like an actual clarinet register key, rather
On 01/29/2013 10:29 PM, m...@mikesolomon.org wrote:
Just a note to say thank you to all those who want to make this code better.
It's tough for me to take it any farther with my non-expert knowledge of
woodwind instruments, but I would be glad to answer any and on questions
addressed to lilypond-
On 01/30/2013 09:42 AM, Wim van Dommelen wrote:
That is why the "low-bass-clarinet" stencil exists. That is (as I reverse
engineer it) intended for bass-clarinet toward low-C (the concert model) whereas
the "bass-clarinet" is the low-Ees (streetmodel).
Well, my point is that "low-bass-clarinet"
On 02/01/2013 07:06 PM, Wim van Dommelen wrote:
Ia there any rule in using Trademarks and mentioning these in the documentation?
This could open up a quagmire because several models of regular clarinets also
have key additions
What key additions did you have in mind? For example low F vent
On 02/01/2013 07:06 PM, Wim van Dommelen wrote:
That would necessarily involve a diagrams for each brand/model combination ?
Otherwise it would be a nightmare to control which key to show and which not.
And to do it so others really can follow it we should name it accordingly, e.g.:
"Selmer-Priv
On 02/05/2013 07:46 AM, David Kastrup wrote:
Disagree. The default conversation language of LilyPond (all its
command and function names) is English, the default note language is
dutch. side-ees is perfectly consistent with LilyPond's defaults.
The problem is not so much the use of Dutch as t
On 02/05/2013 01:38 PM, Wim van Dommelen wrote:
As for the mainstream of users: it is marvellous all these languages are
supported natively for all notes to enter. Building a rather specialized diagram
is only for a very small fraction. So I'll go for having the diagram right based
on the Dutch (
On 02/07/2013 02:26 PM, Wim van Dommelen wrote:
clarinet-family --> clarinet (what we have now, but without the "hole")
"hole" ? I guess you mean the extra touchpiece on the LH 1st finger?
Ideally you'd like to have some backwards compatibility, so I suggest keeping
"clarinet" for the b
On 02/07/2013 09:22 PM, Wim van Dommelen wrote:
Mmmh, that (lh . (gis)) is already taken for the upper key, using the same, not
completly describing name will again confuse others.
OK, fair enough, clarinet-lh-low-gis is better, then.
I'd use clarinet-full-boehm as the name for the clarinet w
On 02/08/2013 10:11 AM, Wim van Dommelen wrote:
But that also has the low-ees, because it still is a "soprano" it sounds higher
then the low-ees in the bass-clarinet. The key lay-out is similar as the
basset-clarinet (which is in A, not B flat). Confusing all this is ...
Not really ... ?
T
On 02/07/2013 02:26 PM, Wim van Dommelen wrote:
The "clarinet-with-low-gis", "bass-clarinet" and "low-bass-clarinet" will then
be "intermediate" stencils, but otherwise complete and callable from the
outside, which is fine for example for writing down a specific thing in the high
registers or a s
On 02/08/2013 12:58 PM, Wim van Dommelen wrote:
Have never seen these 4 key-versions, but might very well be possible.
Used to be the norm -- the earliest examples in the clarinet family are basset
clarinets and basset horns dating from the end of the 18th century (i.e.
contemporary with Moza
On 02/08/2013 05:30 PM, Wim van Dommelen wrote:
Mmmh, but the correct use of it is vital. See e.g. Sparnaay pages 57 and 58. By
looking back to these pages I noticed he writes the usage of the hole with a
cross in circle "one". Henri Bok does the same. I like the graphical
representation along th
On 02/08/2013 09:03 PM, Wim van Dommelen wrote:
I agree it needs an explanatory diagram at hand and it also calls for a
possibility to have a numeric entry for specifying which key(s) to use for which
note. But through the years I've learned that coming back with these kind of
global things later
On 02/10/2013 05:21 PM, Luca Rossetto Casel wrote:
Another one,
http://www.youtube.com/watch?v=m5uPPJj_M_o
Does anyone know anything about the computer engraving software shown in this
second video? I don't recognize it, but it's striking how similar it looks to
Lilypond.
_
On 02/10/2013 09:08 PM, Henning Hraban Ramm wrote:
No it doesn’t ;-)
I know it's _not_ Lilypond, but it does appear to share some similarities.
It’s SCORE, see http://en.wikipedia.org/wiki/SCORE_(software)
Doesn't look like SCORE markup to me:
http://www.ccarh.org/courses/253/handout/scorei
On 02/12/2013 03:05 AM, David Kastrup wrote:
The advantage LilyPond has over the hand engraver is that it does not
need to say "I don't make mistakes". The hand engraver puts down the
staff lines, and short of throwing the plate(s) away and starting over,
the layout has to fit those lines, and t
On 02/12/2013 12:48 PM, David Kastrup wrote:
Looks we are missing the proper command for this. With \pitchedTrill,
transposition works.
Yes, absolutely. A proper command would also help with the appearance -- as it
stands getting the accidental placed just right over the trill sign is a bit
On 02/12/2013 01:24 PM, Janek Warchoł wrote:
we have a snippet
Documentation/snippets/transposing-pitches-with-minimum-accidentals-smart-transpose.ly
The problem with this snippet is that it's conceived as a function that "wraps"
a given piece of music. But as I recall, if you put a transposi
On 02/12/2013 02:50 PM, David Kastrup wrote:
Joseph Rushton Wakeling writes:
What you actually want to see in a given passage is something like,
{
\set Staff.transposition = #'chromatic
c'4 bf' gs' e'% any transposition applied to this passage
On 02/12/2013 08:41 PM, David Kastrup wrote:
If you want different passages in music behave differently when included
in a single \transpose command, that more or less means that they need
to use different callbacks at least in some anchoring expressions (like
we use a relative-callback for doing
On 02/14/2013 01:36 PM, David Kastrup wrote:
a) a reliable and scaleable mechanism to make individual problems go
away by manual labor. WYSIWYG systems offer that. I think that
Frescobaldi tries offering a bit of that as well.
The really simple way of putting this: "It needs to be as easy as
On 02/14/2013 04:17 PM, David Kastrup wrote:
Uh, they fired the original developers and their team without much of a
migration strategy. It is unlikely that substantial new developments
are planned, or this would have been an economically stupid course.
I'm not saying it was a smart thing to d
On 02/14/2013 04:44 PM, Urs Liska wrote:
While it may not seem to be intuitive you can actually write extremely robust
"house style" sheets (or rather libraries which I find much more reliable than
any preset templates or whatever you could use with WYSIWYG software.
With the additional advantage
On 02/14/2013 05:32 PM, Urs Liska wrote:
Maybe I'll get in touch with you before. I already intended to present the
outline of the presentation here and ask for feedback - I think it's an issue
that concerns many of us ...
(The presentation is due at the end of April, so it will be some time stil
On 02/17/2013 01:10 PM, Javier Ruiz-Alma wrote:
I found an accidental notation rule in 1803 music introductory textbook by M.
Clementi, says accidental was also omitted on the following bar it when happened
to be first note played of same pitch as prior bar accidental (explicit example
shown invo
On 02/17/2013 04:48 PM, Luca Rossetto Casel wrote:
In present editions, this notation is generally uniformed to the modern one -
eventually putting the added alterations in parentheses or brackets.
Is this really a case where brackets would be used? The typical reason for
inserting a brackete
On 02/18/2013 03:17 AM, Luca Rossetto Casel wrote:
Yes, in most cases brackets are indeed unnecessary. But I know some
over-accurate editions that aim to reproduce the original text as faithfully as
possible, giving evidence to every critical intervention - for example, the
Ricordi critical editi
(Apologies to David, I hit "Reply" instead of "Reply List" when first writing
this response.)
On 02/22/2013 12:10 AM, David Kastrup wrote:
If the file format describes exactly how the finished score will appear,
what will happen with the spacing when transposing? Presumably it is
ingrained int
On 02/22/2013 09:02 PM, Henning Hraban Ramm wrote:
I think his point was that _no_ file format ever describes exactly how the
finished score would appear
No? We have PDF. Maybe they have too. >:->>
Write once, read many, edit difficult ;-)
___
l
On 02/27/2013 11:41 AM, Han-Wen Nienhuys wrote:
I am and have been ambivalent about being part of the GNU project. It
has come with a lot of harping about how we should say things (like
insisting on naming Linux as "GNU/Linux"), with little in return.
At the risk of opening up a can of worms,
On 02/28/2013 02:30 AM, Adam Spiers wrote:
I don't follow your logic here at all. Being large and complex
doesn't rule it out from being a starting point. If it *wasn't*
large, there wouldn't be as much to gain from starting with it
vs. starting from scratch.
You make two rather big assumptio
On 02/28/2013 02:11 PM, Daniel Rosen wrote:
I'm typesetting a piece of vocal music, and I want to have a melisma without a
slur being drawn. I tried \override Slur #'stencil = ##f, but when I compiled
it, the output appeared as if I had written \override Slur #'transparent =
##t--in other word
On 02/28/2013 06:20 PM, Adam Spiers wrote:
I strongly disagree, unless your definition of "difficult" ignores
the time dimension of such a project.
http://www.joelonsoftware.com/articles/fog69.html
It can go horribly wrong, yes, but it doesn't have to. Git for example was a
from-scra
On 03/01/2013 06:17 PM, Guy Stalnaker wrote:
Is it possible to modify the brace from a GrandStaff or the positioning of the
brace for the PianoStaff version so that it is more like the B&H engraving? I
know the example from the LP documentation is acceptable (the Peter's Edition of
the Bach is en
On 03/02/2013 06:22 PM, Urs Liska wrote:
OTH we might take this as an opportunity to do something else as a showcase
project.
I wouldn't suggest Goldberg Variations but rather something complex from the end
of the 19th century (i.e. just out of copyright). Maybe something for string
quartet too
On 03/02/2013 06:27 PM, Joseph Rushton Wakeling wrote:
Alban Berg 4 Pieces for Clarinet and Piano. Out of copyright in the US
(pre-1922 publication) and Europe (more than 70 years since composer's death).
On IMSLP here: http://imslp.org/wiki/Special:ImagefromIndex/12907
To me this
On 03/02/2013 06:30 PM, Urs Liska wrote:
I also thought of Berg already. Maybe also his songs? (could prove useful for me
when having to play transpositions ...)
But the Clarinet Pieces are beautiful too. Good point.
Well, tell you what. If I put together a rough version of the 4 Pieces and ge
On 03/02/2013 06:43 PM, Jethro Van Thuyne wrote:
"Renewed copyright 1952 by Helene Berg". How long did/does such a renewal run?
Well, this is the discussion on the subject on IMSLP's forums:
http://imslpforums.org/viewtopic.php?f=13&t=3503
I believe that typical terms of copyright renewal were
Hello all,
Taking a look at Berg Op. 5 (see Sibelius-related discussion) I realized that it
uses a slight variant of the "dodecaphonic" accidental style: every note has an
accidental, but only for its _first_ appearance in the bar.
Any advice on how to achieve this automatically?
Thanks & be
On 03/02/2013 08:02 PM, Urs Liska wrote:
But let me make a further suggestion:
As I already mentioned in an earlier thread I'm going to write a paper on
plain-text, git-driven work-flows, and I would be pleased if I could use this
project as example material for that.
The motivation for the paper
On 03/02/2013 07:45 PM, Urs Liska wrote:
AFAIK (but I'm not a lawyer either) you can't renew the copyright of the music
but only on editions. That's why one sometimes has to pay royalties for really
old music.
This is UnitedStatesian copyright law, which has historically had some amusing
devia
On 03/04/2013 05:29 PM, Trevor Bača wrote:
Is anyone else out there using Ferneyhough-style flared hairpins?
I'd probably use them if they were available.
I'm considering sponsoring the work and I'm curious to know if there would be
any other adopters if the feature were implemented.
Actual
On 03/04/2013 05:29 PM, Trevor Bača wrote:
I'm considering sponsoring the work and I'm curious to know if there would be
any other adopters if the feature were implemented.
... could we make this a 2-in-1 to also cover his
brackets-to-show-extent-of-dynamic notation? This actually couples wit
On 03/26/2013 09:52 AM, David Kastrup wrote:
> I met a former colleague in the bus to Chemnitz, and he is at least
> knowledgeable about EU research programmes. Do people here have ideas
> about possible institutions who could be made to participate?
Imperial College, London has a fairly close re
Hello all,
A question which has come up, and where I'm not sure what the answer or
intention is.
Lilypond is licensed under the GPL and reading through the license file, I
didn't come across any granted exceptions (IIRC the fonts have an exception for
embedding them into a document).
So, how doe
On 03/28/2013 06:35 PM, David Kastrup wrote:
> I don't see that. \include is an instruction, not an actual inclusion.
> As opposed to dynamic linking, there is no combined entity being formed
> for the sake of execution where one could possibly claim "contributory
> infringement". The inner worki
On 03/28/2013 08:28 PM, Tim McNamara wrote:
> My understanding is always been that the GPL applies to the software used to
> produce a file, not to the file itself.
I think (at least in this case) you mean "process", not "produce".
You can draw an analogy to e.g. shell scripts, where the fact th
On 03/29/2013 10:39 PM, Urs Liska wrote:
> First of all, I think we have quite a consensus on what we intend - which is
> a good start.
Yup. :-)
> I slightly disagree, although your considerations are valuable and give some
> good insights in the situation.
> I think the 'ambiguity' Joe is talk
On 03/29/2013 11:26 AM, Janek Warchoł wrote:
> On Thu, Mar 28, 2013 at 7:26 PM, Joseph Rushton Wakeling
> wrote:
>> but aside from that I think there are
>> probably several other ways in which it could be done, including ensuring
>> that
>> all files intended to be
On 03/30/2013 01:02 AM, Alexander Kobel wrote:
> On the other hand, user C /should/ be allowed to distribute source code under
> whatever license he wants to /as long as he doesn't ship the GPL libraries
> with
> it./ It's useless without them, but anybody who wants to run or compile the
> code i
On 04/02/2013 03:52 PM, David Kastrup wrote:
> The main difference is "work as a whole" vs "mere aggregation". If you
> include some file as a form of invoking its documented interface, you
> form no new combined work.
Indeed, which if I recall right is how Google was able to provide non-GPL'd
he
On 04/02/2013 05:07 PM, Alexander Kobel wrote:
> This certainly applies to compiled code, with the GPL'ed library statically
> linked, and also (I stand corrected) with dynamic linkage, AFAIU. I still
> cannot see how it /could/ possibly apply to source code:
Well, the examples you cite consider
On 04/02/2013 07:07 PM, Urs Liska wrote:
> My suggestion would be to either have a sort of "lilypond license" or
> (better) an explicit exception/clarification stating that the use of
> functions defined in the LilyPond distribution (either implicit or through an
> explicit include) do not requi
On 04/02/2013 07:33 PM, Tim McNamara wrote:
> If I do not copy the actual file into my .ly file but only have the \include
> statement, I have not violated copyright. It would be up to any subsequent
> user to obtain the copyrighted Bob Jones file to use with \include or to come
> up with a wor
On 04/02/2013 08:53 PM, David Kastrup wrote:
> LilyPond is a GNU program and so follows the licensing policies of the
> GNU project.
Sure, but I don't see that this prevents you from making a permissive licensing
choice for parts of your program where this is appropriate -- I imagine the GNU
proje
On 04/02/2013 09:50 PM, Tim McNamara wrote:
> On Apr 2, 2013, at 12:47 PM, Joseph Rushton Wakeling wrote:
>> But now suppose that bobjones.ly defines a number of new functions, \bobFoo,
>> \bobBar, etc., and that you use them on a number of occasions throughout your
>> own .l
On 04/02/2013 10:33 PM, David Kastrup wrote:
> Since I can't share your concerns, I can't give you any advice what to
> ask the SFLC in order to address them. That's quite up to you.
Fair enough. I was concerned that you might actively disapprove of my doing so,
in which case I'd have wanted to
On 04/02/2013 11:17 PM, Anthonys Lists wrote:
> So as long as Google stuck to using interfaces that the kernel devs explicitly
> published to user space, then using those header files EXPLICITLY does NOT
> create a derivative work, and therefore the GPL can NOT cross that boundary.
That's exactly
On 04/02/2013 11:28 PM, Anthonys Lists wrote:
> A derivative work is whatever the LAW says it is (whatever that is :-). NO
> open
> source licence defines the term "derivative work", although they may give
> their
> own interpretation of what they think it is.
The actual GPL term is a "covered w
On 04/02/2013 11:25 PM, David Kastrup wrote:
> Uh, so far I have just seen fantasizing about TeX users having similar
> concerns.
I did post a link before:
http://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages
Sure, it's not a huge wellspring of concern, but as you say, that's .
On 04/03/2013 12:01 AM, Anthonys Lists wrote:
> But as I understand it, the lawsuit as actually sued said "apis are copyright"
> and you would have needed a licence to use the apis - to use Oracle's Java.
That's exactly in line with what David said. Google were providing a clean-room
re-implement
On 04/02/2013 11:57 PM, Anthonys Lists wrote:
> On 02/04/2013 22:47, Joseph Rushton Wakeling wrote:
>> Indeed, and a consequence of distributing a "covered work" under
>> GPL-incompatible terms is that you lose the permissions granted under that
>> license.
>
&
On 04/02/2013 11:38 PM, Anthonys Lists wrote:
> On 02/04/2013 22:01, Joseph Rushton Wakeling wrote:
>> (Function names and APIs are generally considered to be uncopyrightable.)
>> However, I think the consensus of opinion about free software licensing would
>> be that, in dis
On 04/03/2013 01:45 AM, Tim McNamara wrote:
> Is that in fact correct? The quibbles here is what constitutes derivation.
> If you write a program that calls a library during its function, is that
> program derived from the library? Or is the library just a resource that the
> application uses
On 04/03/2013 01:22 AM, David Kastrup wrote:
> Yes, it is. The terms of use of a proprietary program generally presume
> a binding contract _restricting_ the scope of rights normally granted
> with the legitimate purchase of media.
>
> The difference is that the proprietary vendor needs to establ
On 04/03/2013 01:14 AM, Anthonys Lists wrote:
> If your work does not include any of their work, then you don't need any
> permission to not copy their work! :-)
But I'm not talking about copying. I'm talking about the right to use.
> And if you read the GPL, version 2 (I presume 3 has similar w
On 04/03/2013 01:08 PM, Wols Lists wrote:
> Dare I suggest you look at section zero? The second paragraph of which
> says, and I quote:
You're talking about GPL version 2, not GPL version 3.
Compare:
https://www.gnu.org/licenses/gpl-2.0.html
... where the second paragraph of Section 0 is exactly
On 04/04/2013 02:50 PM, Alexander Kobel wrote:
> Then, everybody is free to use "my-app.C" constraint to my terms, since they
> are
> imposed on this very file. However, nobody would be allowed to use /GSL/ to
> compile this program, because GPL considers "my-app.C" a covered work
> /whenever
>
On 04/06/2013 10:50 PM, Janek Warchoł wrote:
> The things is, use git for tracking source files, not pdfs. If you
> put \version statements in all your .ly files, you can always recreate
> a pdf with appropriate LilyPond version.
>
> Actually, it might make sense to track some pdfs as well, but i
On 04/07/2013 09:23 AM, David Kastrup wrote:
> Have you tried with LilyPond PDFs? I think they tend to compress on the
> object level which _might_ work reasonably with some of git's packing
> techniques.
No. I did take a look inside them before writing my previous email -- they
certainly have m
On 04/07/2013 06:51 PM, Stjepan Horvat wrote:
> I realy like git too..Once i tried to make my own git server on my private
> web-server so when i finish the work i can send the customer his pdf folder
> link..but..that didnt work becouse you cant see actual files on git web
> server..like you can o
On 04/09/2013 06:26 PM, Urs Liska wrote:
> When I used Finale one had to draw a rectangle with the mouse that then was
> exported.
> Needless to say that this is a poor way to consistently line up music
> fragments
> in a text document.
I doubt this is the way a hardcore professional engraving pe
On 04/24/2013 04:36 PM, Owain Sutton wrote:
> Another common option is simply indicating 'vib.', 'senza vib.', 'molto vib.'
Depends how precise a visual indicator you want to have of the type of vibrato,
particularly with respect to precise indication of the 'vertical' extent (i.e.
the range of pi
Hello all,
A query about MIDI export, which relates to a feature request I have in mind but
would like to confirm is feasible.
Lilypond's MIDI export has problems with partial opening measures. This means
that import into other programs will fail to place barlines correctly, and that
MIDI p
On 02/04/12 22:55, Nils wrote:
Midi understands time signatures:
What I did in Laborejo.org is to start with a measure which has a timesignature
of the length of the upbeat and after that place the original timesig.
Ahh, from a playback point of view that's a nicer tweak than rests at the star
On 30/05/12 02:12, Han-Wen Nienhuys wrote:
One of the problems of LilyPond is that C++ had very poor support for
things we desperately need: reflection, automatic memory management
and callbacks.
How about D?
http://dlang.org/
This seems to me to be a great choice for much of LP's needs. C/C
On 03/06/12 14:17, David Kastrup wrote:
How about first getting C++/Scheme right? As I already explained,
cleaning up the mess of layers and control flow will
a) give a better basis for judging that approach
b) make it easier to migrate individual layers to something else if
desired
Don't
1 - 100 of 182 matches
Mail list logo
