Re: Early (very early) project: The Celtic Song Book (c) 1928

> - In older music with lyrics it was common to see beams broken for each > syllable. Today it's common practice to not do that. I'll leave it up to > you to decide which style you want to follow. It sounds like you're using > an older edition for a source. That is not totally a thing of old pract

Licensing and custom lines

Dear Lilypond community, --- 1. About GPL licensing, again. Sorry to bother you, but I'm confused by this : "All code linked with GPL 3.0 source code must be disclosed under a GPL 3.0 compatible license." from the GPL license. And this : https://www.mail-archive.com/lilypond-user@gnu.org/msg13

Re: Early (very early) project: The Celtic Song Book (c) 1928

> > - In older music with lyrics it was common to see beams broken for each > > syllable. Today it's common practice to not do that. I'll leave it up to > > you to decide which style you want to follow. It sounds like you're using > > an older edition for a source. > > That is not totally a thing

Re: Licensing and custom lines

Charlie Boilley writes: > Dear Lilypond community, > > --- > 1. About GPL licensing, again. > > Sorry to bother you, but I'm confused by this : > > "All code linked with GPL 3.0 source code must be disclosed under a > GPL 3.0 compatible license." from the GPL license. That's utter nonsense and n

Re: Licensing and custom lines

On 10/28/2021 2:30 AM, Charlie Boilley wrote: how can be 100% sure For some kinds of intellectual property questions, such certainty may not be available. If the question affects a very large and expensive production, consulting with a qualified attorney may be in order. For my own person

Re: Licensing and custom lines

Don't worry about that. The GPL takes effect when you modify or integrate Lilypond in some product you release to the public. A score created by Lilypond is not such a product. Regarding snippets: While Lilypond is a tool you are explicitely licensed to use personally and professionally, snippe

Re: Licensing and custom lines

From: lilypond-user on behalf of Charlie Boilley Date: Thursday, October 28, 2021 at 1:37 AM To: "lilypond-user@gnu.org" Subject: Licensing and custom lines Dear Lilypond community, --- 1. About GPL licensing, again. Sorry to bother you, but I'm confused by this : "All code linked with GP

Re: Licensing and custom lines

On Thu 28 Oct 2021 at 07:30:15 (+), Charlie Boilley wrote: > Dear Lilypond community, > > --- > 1. About GPL licensing, again. > > Sorry to bother you, but I'm confused by this : I think somebody else keeps on discussing this topic. I nearly deleted the thread on that basis alone; in my mind

Re: Licensing and custom lines

Hello Carl, in fact using proprietory Software would be worse, as with these you usually have no license at all for redistributing the software or derivates. So basically it would illegal to publish anything created with such software under any circumstances, unless you are specifically licensed

New lines (whishlist) ... ?

Hi, The latest Lily release is very welcomed with great contempory lines and layout objets rotation, thank you ! Would it be possible to : - Combine multiple shapes into one line (with primitives : sin, tri, square, saw, Bravura glyphs, ...) ? - Stretching the line with anchor points ex. one

Re: Licensing and custom lines

From: Valentin Petzel Date: Thursday, October 28, 2021 at 8:42 AM To: Carl Sorensen Cc: Charlie Boilley , "lilypond-user@gnu.org" Subject: Re: Licensing and custom lines Hello Carl, in fact using proprietory Software would be worse, as with these you usually have no license at all for redis

Re: Early (very early) project: The Celtic Song Book (c) 1928

Hi Valentin, >> - In older music with lyrics it was common to see beams broken for each >> syllable. Today it's common practice to not do that. > That is not totally a thing of old practise/new practice. > Conventional vocal practise is to have beams align with melismas. As an engraver, and as b

Re: New lines (whishlist) ... ?

Hi, If you search in the mailing list archives you will find little bits of code that partially achieve what you want. If you actually want a sleek official solution for a future stable version this is going to take a while I imagine. Sort answer: all of that is possible but the required ease of

Re: Sending around contexts

Hi all! I’m wondering if the state-of-the-art on pushing grobs to a “remote” context has improved since last year? I’ve included a snippet (below) from the thread which includes the message . 1. Instead of \pfdyn g'1

Re: Sending around contexts

Hi again, > On Oct 28, 2021, at 2:03 PM, Kieren MacMillan > wrote: > > 2. Maybe even better: Would a Scheme engraver be able to extract (and > “delete”/omit) *all* dynamics from one context (e.g., the piano_upper > context) and inject them into a second context (e.g., piano_dynamics)? If so,

Re: Sending around contexts

Hello Kieren, The Container solution I did back then got kind of more complicated with 2.22, as the behaviour of overrides changed. So now if we use such containers each override has to specify the Voice path, which was not nescessary before. A different method I thought about is using NullVoic

Re: Sending around contexts

On 2021-10-28 11:27 am, Kieren MacMillan wrote: 2. Maybe even better: Would a Scheme engraver be able to extract (and “delete”/omit) *all* dynamics from one context (e.g., the piano_upper context) and inject them into a second context (e.g., piano_dynamics)? If so, what would be the most elegan

Re: Sending around contexts

On 2021-10-28 12:25 pm, Aaron Hill wrote: Not an engraver, but a dispatcher trick could be a first step: Wait... there's no need to share a source dispatcher... also, that code duplicates the listener... \version "2.22.0" #(define event-transfer-sink (ly:make-dispatcher)) eventTransfer

Re: Sending around contexts

Hi Aaron, \version "2.22.0" #(define event-transfer-sink (ly:make-dispatcher)) eventTransferSink = \applyContext #(lambda (ctxt)  (ly:connect-dispatchers   (ly:context-event-source ctxt)   event-transfer-sink)) eventTransferSource = #(define-music-function (event-type) (symbol?)   (define

Re: Sending around contexts

Hi Lukas (and Aaron), > Wow. Agreed. > That's what you might call elegant (and I have to admit that this is the > first time I hear about dispatchers). +1 x 2 (which, ironically, still equals 1…) > But as I imagine Kieren is going to want to use this a LOT :-) YOU DON’T KNOW ME!!! ;) Yeah… t

Re: Sending around contexts

Hi Valentin, > A different method I thought about is using NullVoice and add the Dynamic > relevant engravers. One can then use tags to determine what events to send to > these NullVoices. I try to avoid the tag mechanism as much as possible (e.g., the edition-engraver has absorbed more than 9

Re: Sending around contexts

Hi Lukas, hi Aaron, This is looking marvellous! I’ve modified Lukas’ version a bit so that we can use tags to control if events are sent and if they are removed in their original location. Also if we define multiple (named) channels we can send events to a specific channel. Cheers, Valentin%%%