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

[Valentin Petzel]

> - 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 practise/new practice. Conventional vocal 
practise is to have beams align with melismas. This has the advantage that 
more complex melismatic lyrics distributions are easy to read. But when you 
have scores with high rhythmical complexity but little melismatic complexity, 
we keep to common beaming (although singers are used to singing quite complex 
rhythms without beams). Also of course in scores for people who do not need 
lyrics like conductor scores you do not want this and instead want regular 
beaming for rhythmic clarity. One can of course try to find a compromise by 
mixing the forms (it is quite common to break beams on a melisma at main 
beats), or by using things like dubdivisions.

In this case the conventional vocal beaming is fine, due to the nature of the 
score. They are just not entirely consistent, as in triplets.

I’ve attached some examples to illustrate the advantages.

Cheers,
Valentin

signature.asc
Description: This is a digitally signed message part.

Licensing and custom lines

[Charlie Boilley]

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/msg136603.html

Then, how can be 100% sure that I can keep :

- my musical work closed source and share it along the license I wany by using 
some scripts from other users or built on snippets ?
https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00398.html

- when sharing scripts with other users ?

- when dev. creative scripts in or linked to Lily that are part of my 
composition as "musical objects primitives" : code that will generate Lily code 
?

How to find solid arguments against :
https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ ?

---
2. New lines !

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 to the left and stretch the 
line to the right in order to make a progressive vibrato or vibrato that would 
change in speed and amplitude multiples times per line in which case each 
anchor point could be vertically linked to some event like a pulse or hidden 
note ?

- Increase or decrease the thickness of the line progressively and at multiple 
times between start and end note ?
- Assign one line to local midi CC like CC1 for vibrato amplitude, linked to 
the height of the line ?

Have a good day !

Yours,
ChB

P.S. : Sorry for the translation.

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

[Michael Gerdau]

> > - 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 practise/new practice. Conventional vocal 
> practise is to have beams align with melismas. This has the advantage that 
> more complex melismatic lyrics distributions are easy to read.
[rest snipped]

I totally agree with that. As a performing singer I very much prefer the mixed 
(3rd) and broken (1st) versions, possibly with an ever so slight preference for 
the mixed one, and then with quite a distance the so called regular (2nd) as of 
Valentin's 3 examples.

Language itself has a rhythm and when lyrics are not just vocalized sound then 
the language and its inherent rhythm almost always is more important.

Kind regards,
Michael
-- 
Michael Gerdau email: m...@qata.de
GPG-keys available on request or at public keyserver

Re: Licensing and custom lines

[David Kastrup]

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 not part of the GPL license.  Where have you
read that since you put it in quote marks?  The GPL does not force you
to disclose anything as long as you don't distribute it (the AGPL is a
bit more complex but that's not relevant for LilyPond).

> And this : https://www.mail-archive.com/lilypond-user@gnu.org/msg136603.html
>
> Then, how can be 100% sure that I can keep :
>
> - my musical work closed source and share it along the license I wany
> by using some scripts from other users or built on snippets ?
> https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00398.html

If you distribute code of LilyPond or scripts of others, you have to
heed their intended license.  LilyPond's code will not usually be
integrated into your source.  Code snippets may be a different thing.
Regarding the LilyPond Snippets collection in the manuals, there is


LilyPond — Snippets
***

This document shows a selected set of LilyPond snippets from the
LilyPond Snippet Repository (http://lsr.di.unimi.it) (LSR). It is in the
public domain.

> - when sharing scripts with other users ?
>
> - when dev. creative scripts in or linked to Lily that are part of my
> composition as "musical objects primitives" : code that will generate
> Lily code ?

What are you concretely talking about?  Obviously there is no "if it is
LilyPond code, it is free for the taking" guarantee: you have to look at
who is providing you with what code under which conditions.

-- 
David Kastrup

Re: Licensing and custom lines

[Karlin High]

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 personal-use things, I've observed the Free Software 
Foundation and the LilyPond community long enough to have a fair idea of 
what they would and would not tolerate for usages of their products.

--
Karlin High
Missouri, USA

Re: Licensing and custom lines

[Valentin Petzel]

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, snippets obtained from some random place are 
usually not licensed specifically. But that would only be an issue if you 
wanted to distribute such code in some product, as long as you just use it 
internally for your score no one is going to say something about it.

Cheers,
Valentin

Re: Licensing and custom lines

[Carl Sorensen]

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 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/msg136603.html

Then, how can be 100% sure that I can keep :

- my musical work closed source and share it along the license I wany by using 
some scripts from other users or built on snippets ?
https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00398.html

You have copyright in the music, not in the engraving.  If your copyright were 
in the engraving, all one would have to do to break your copyright is to 
re-engrave the music.

As long as you distribute only engravings (output from LilyPond), there is no 
assertion in GPL of a need to release source, as described in my answer to 
Karsten.  You are free to keep the source used for the engraving closed and 
share it with nobody.

- when sharing scripts with other users ?

If you share your own scripts with others, you are free to put them into any 
license you want.

- when dev. creative scripts in or linked to Lily that are part of my 
composition as "musical objects primitives" : code that will generate Lily code 
?

Code that will generate LilyPond code is your creation.  You can do whatever 
you want with it.  You are not required to share the source of your code by the 
GPL.  You will probably need to avoid distributing it along with LilyPond in 
order to make it clear that you are not creating a derivative work of LilyPond.

How to find solid arguments against :
https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ ?

IMO, the real answer to this question is another question:  How to find solid 
arguments in favor of Karsten’s post?  If he could provide a single case where 
the output of a GPL program has been required to be put under the GPL (*any* 
GPL program, not restricted to LilyPond), then I would consider his arguments 
valid.  But I have never heard of one, and he provides no citations of the 
problem.

How does GPL apply to LilyPond and derivative works?  It applies to creating 
works for engraving music, not engraved music works.  If you were to make *and 
distribute* a  version of LilyPond (call it SuperLily3) that took all of the 
Guile parts of LilyPond, along with a set of lilypond snippets written in 
Guile, and convert them all to compiled byte code, and distribute that (as a 
way to avoid the compiling time in Guile3), then you would be required by the 
GPL to provide your source code *and* the scripts you use to compile all the 
Guile bits to byte code and install them in the proper directories to anybody 
who asked.  Which means that they could then implement them in LilyPond.  But 
if you were only to make *and never distribute* SuperLily3, you are free to use 
it however you wish, and the GPL does not require you to share your source.

I don’t think worrying about having to share sources for your engraving if you 
share your engraving is a real issue at all.  I think it’s a made up issue.  
But if you are worried about it, you probably shouldn’t use LilyPond.  And you 
shouldn’t use LibreOffice for writing any text, and you shouldn’t use Inkcsape 
for making any graphics, and you should probaby stick to the closed-source, 
commercial software world.  For me, that would be a terrible tradeoff.  Use the 
best tools available for engraving your music, and don’t worry about 
hypothetical problems that GPL might impose on your distributions of the output 
of a program in some hypothetical world.  There’s zero evidence of that 
happening in the real world.

Best wishes,

Carl

Re: Licensing and custom lines

[David Wright]

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, it's never been an unsettled matter, but just
a confusion between LP source and LP source, ie a case
for having a clear terminology.

> 2. New lines !

So I would repost this section under a clearer Subject line,
perhaps including "wishlist": you might get more readers.

Cheers,
David.

Re: Licensing and custom lines

[Valentin Petzel]

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 to do so.

Cheers,
Valentin

New lines (whishlist) ... ?

[Charlie Boilley]

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 to the left and stretch the 
line to the right in order to make a progressive vibrato or vibrato that would 
change in speed and amplitude multiples times per line in which case each 
anchor point could be vertically linked to some event like a pulse or hidden 
note ?

- Increase or decrease the thickness of the line progressively and at multiple 
times between start and end note ?

- Assign one line to local midi CC like CC1 for vibrato amplitude, linked to 
the height of the line ?

Have a good day !

Yours,
ChB

Re: Licensing and custom lines

[Carl Sorensen]

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 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 to do so.

You do not need a license to distribute works created using the software.  They 
are not considered “derivative works”.  Karsten (in his original post) claimed 
that “non-source-forms” in the GPL applied to works created using the software, 
which is an interpretation I have never used anybody else make.

The licenses for proprietary software don’t include any special requirements on 
“non-source-forms”, because all that exists is the non-source form of the 
program as distributed.  And the license terms prevent all distribution (and 
usually disassembly, reverse engineering, etc.) of the licensed materials, but 
mention no restrictions on the output created using the program.

Thanks,

Carl

P.S. I agree it’s worse to use proprietary software, but not because it creates 
more onerous licensing terms.  IMO, both proprietary licenses and the GPL are 
equivalent in their effect on the licensing of objects created by using the 
programs: they have no effect on the output.  But Karsten disagrees with that 
assertion; I think it’s a straw man argument.

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

[Kieren MacMillan]

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 both a choral conductor and singer, I must disagree: the 
overwhelming majority of contemporary choral scores exhibit “instrumental 
beaming” (i.e., beaming to the beat/meter) — it is now the convention (a.k.a. 
“new practice”) — and melismatic beaming (a.k.a. “old practice”) is almost 
unseen nowadays.

This is confirmed by Elaine Gould in “Behind Bars” (p. 435): “Until well into 
the twentieth century, a separate tail was used for each syllable in vocal 
music, and notes within a beat were beamed only to indicate that a syllable 
took more than one note. […] Instrumental beaming (i.e. beaming into beats) is 
now used in vocal music together with syllabic slurs”.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: New lines (whishlist) ... ?

[Dimitris Marinakis]

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 use and
smartness of the code can massively complicate the solutions.

The only think I can almost definitely say won't happen is the last one
since I haven't seen such deep integration of (realtime?) MIDI input to
advanced features of Lilypond in my experience. Most advanced users I've
seen active rarely integrate MIDI in their code. In fact there isn't any
notation software that lets you manipulate non fixed objects with MIDI in
such a way. I'm not saying it isn't cool I'm just lowering the expectations
since coding just the spanner functions alone won't be insignificant.


On Thu, Oct 28, 2021 at 5:56 PM Charlie Boilley 
wrote:

> 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 to the left and stretch
> the line to the right in order to make a progressive vibrato or vibrato
> that would change in speed and amplitude multiples times per line in which
> case each anchor point could be vertically linked to some event like a
> pulse or hidden note ?
>
> - Increase or decrease the thickness of the line progressively and at
> multiple times between start and end note ?
>
> - Assign one line to local midi CC like CC1 for vibrato amplitude, linked
> to the height of the line ?
>
> Have a good day !
>
> Yours,
> ChB
>
>

Re: Sending around contexts

[Kieren MacMillan]

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 <>\mp

can grobs be “pushed” in a more intuitive/natural way, e.g.

g'1 -\pfdyn -\mp

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 elegant way of indicating that a single/particular dynamic marking 
*shouldn’t* be extracted/pushed by the engraver?

Thanks,
Kieren.

p.s. David K: I added you as a CC because you know your way around the Lilypond 
insides better than anyone I know! Apologies if the direct-email was 
inappropriate.


%%%  SNIPPET BEGINS  %%%
\version "2.22.1"

\layout {
  \context {
\name "Notes"
\type "Engraver_group"
  }
  \context {
\Voice
\accepts "Notes"
  }
  \context {
\name "Container"
\type "Engraver_group"
\accepts "Notes"
\accepts "Voice"
  }
  \context {
\Staff
\accepts "Container"
  }
  \context {
\Dynamics
\accepts "Container"
  }
}

send =
#(define-music-function (cname context music1 music2) (string? string? 
ly:music? ly:music?)
   #{
 << #music1 \new Container \new Notes { \change #cname = #context #music2 } 
>>
   #})

pfdyn = \send Container "piano_dynamics" \etc

piano_upper = {
  c'4\p d' e' f'
  \pfdyn g'1 <>\mp
  g'4\f f' e' d'
  c'1
}

piano_lower = {
  \clef bass
  c1
  g,1
  g,1
  c1
}

\score {
  <<
\new PianoStaff <<
  \new Staff \piano_upper
  \new Dynamics \new Container = "piano_dynamics" s1
  \new Staff \piano_lower
>>
  >>
  %%%  layout mod to show the centred dynamics
  \layout {
\context {
  \PianoStaff
  \override VerticalAxisGroup.staff-staff-spacing.padding = #10
}
  }
}
%%%  SNIPPET ENDS  %%%



Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Sending around contexts

[Kieren MacMillan]

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, 
> what would be the most elegant way of indicating that a single/particular 
> dynamic marking *shouldn’t* be extracted/pushed by the engraver?

In other words, is something like this possible?

\version "2.22.1"

Dynamics_mover_engraver = FOO

piano_upper = {
  c'4\p d' e' f'
  g'1\mp
  g'4\f f' e' d'
  c'1
}

piano_lower = {
  \clef bass
  c1
  g,1
  g,1
  c1\ff
}

\score {
  <<
\new PianoStaff <<
  \new Staff \with { \consists Dynamics_mover_engraver } \piano_upper
  \new Dynamics #(skip-of-length piano-upper)
  \new Staff \with { \consists Dynamics_mover_engraver } \piano_lower
>>
  >>
}

where all the dynamics in either of the two Staff contexts would appear in the 
Dynamics context instead?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Sending around contexts

[Valentin Petzel]

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 NullVoice and add the Dynamic 
relevant engravers. One can then use tags to determine what events to send to 
these NullVoices.

The problem with this is that if the music contains new Contexts like Voices 
then this escapes the NullVoice. I think maybe it would be nice to have an 
„default Voice” context, that behaves like the parent Voice (Voice, TabVoice, 
NullVoice, DrumVoice, etc.)

Cheers,
Valentin

signature.asc
Description: This is a digitally signed message part.

Re: Sending around contexts

[Aaron Hill]

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 elegant way of indicating that a 
single/particular dynamic marking *shouldn’t* be extracted/pushed by 
the engraver?


Not an engraver, but a dispatcher trick could be a first step:


\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))

#(define event-transfer-source (ly:make-dispatcher))
eventTransferSource =
#(define-music-function (event-type) (symbol?)
  (define (event-proc ev)
   (ly:broadcast event-transfer-sink (ly:event-deep-copy ev)))
  (define (context-proc ctxt)
   (ly:connect-dispatchers
event-transfer-source
(ly:context-events-below ctxt)))
  (ly:add-listener event-proc event-transfer-source event-type)
  #{ \applyContext #context-proc #})

piano_upper = {
  c'4\p d' e' f'
  g'1\mp
  g'4\f f' e' d'
  c'1
}

piano_lower = {
  \clef bass
  c1
  g,1
  g,1
  c1\ff
}

\score {
  <<
\new PianoStaff <<
  \new Staff \with { \eventTransferSource dynamic-event } 
\piano_upper
  \new Dynamics \with { \eventTransferSink } { #(skip-of-length 
piano_upper) }
  \new Staff \with { \eventTransferSource dynamic-event } 
\piano_lower

>>
  >>
}


This duplicates events by necessity, because I do not believe you can 
guarantee that the event transfer process is first to intercept an 
event.  As such, it may have already been processed by another engraver. 
 In the above example, you can \omit DynamicText within the two staves 
and get what looks to be the desired goal, but that would mean losing 
all such grobs in those contexts.



-- Aaron Hill

Re: Sending around contexts

[Aaron Hill]

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))
eventTransferSink = \applyContext
#(lambda (ctxt)
 (ly:connect-dispatchers
  (ly:context-event-source ctxt)
  event-transfer-sink))

eventTransferSource =
#(define-music-function (event-type) (symbol?)
  (define (event-proc ev)
   (ly:broadcast event-transfer-sink (ly:event-deep-copy ev)))
  (define (context-proc ctxt)
   (ly:add-listener event-proc (ly:context-events-below ctxt) 
event-type))

  #{ \applyContext #context-proc #})

piano_upper = {
  c'4\p d' e' f'
  g'1\mp
  g'4\f f' e' d'
  c'1
}

piano_lower = {
  \clef bass
  c1
  g,1
  g,1
  c1\ff
}

\score {
  <<
\new PianoStaff <<
  \new Staff \with {
\eventTransferSource dynamic-event
\omit DynamicText
  } \piano_upper
  \new Dynamics \with { \eventTransferSink } { #(skip-of-length 
piano_upper) }

  \new Staff \with {
\eventTransferSource dynamic-event
\omit DynamicText
  } \piano_lower
>>
  >>
}



-- Aaron Hill

Re: Sending around contexts

[Lukas-Fabian Moser]

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 (event-proc ev)
   (ly:broadcast event-transfer-sink (ly:event-deep-copy ev)))
  (define (context-proc ctxt)
   (ly:add-listener event-proc (ly:context-events-below ctxt) 
event-type))

  #{ \applyContext #context-proc #})


Wow.

That's what you might call elegant (and I have to admit that this is the 
first time I hear about dispatchers).


But as I imagine Kieren is going to want to use this a LOT :-), it might 
be reasonable to use named transfer channels:



\version "2.22.0"

newChannel =
#(define-scheme-function () () (ly:make-dispatcher))

receiveFromChannel =
#(define-music-function (chan) (ly:dispatcher?)
   #{
 \applyContext
 #(lambda (ctxt)
    (ly:connect-dispatchers
 (ly:context-event-source ctxt)
 chan))
   #})

sendToChannel =
#(define-music-function (chan event-type) (ly:dispatcher? symbol?)
  (define (event-proc ev)
   (ly:broadcast chan (ly:event-deep-copy ev)))
  (define (context-proc ctxt)
   (ly:add-listener event-proc (ly:context-events-below ctxt) event-type))
  #{ \applyContext #context-proc #})

piano_upper = {
  c'4\p d' e' f'
  g'1\mp
  g'4\f f' e' d'
  c'1
}

piano_upper_II = {
  c'4\ff\< d' e' f'
  g'1\
  g'4 f' e' d'
  c'1
}

piano_lower = {
  \clef bass
  c1
  g,1
  g,1
  c1\ff
}

myChannel = \newChannel
myOtherChannel = \newChannel

\score {
  <<
    \new PianoStaff <<
  \new Staff \with {
    \sendToChannel \myChannel dynamic-event
    \omit DynamicText
  } \piano_upper
  \new Dynamics \with { \receiveFromChannel \myChannel } { 
#(skip-of-length piano_upper) }

  \new Staff \with {
    \sendToChannel \myChannel dynamic-event
    \omit DynamicText
  } \piano_lower
    >>
    \new PianoStaff <<
  \new Staff \with {
    \sendToChannel \myOtherChannel dynamic-event
    \sendToChannel \myOtherChannel span-dynamic-event
    \omit DynamicText
    \omit Hairpin
  } \piano_upper_II
  \new Dynamics \with { \receiveFromChannel \myOtherChannel } { 
#(skip-of-length piano_upper) }

  \new Staff \with {
    \receiveFromChannel \myOtherChannel
  } \piano_lower
    >>
  >>
}


Lukas

Re: Sending around contexts

[Kieren MacMillan]

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… this will end up getting overused in my code.

> 
> \version "2.22.0"
> 
> newChannel =
> #(define-scheme-function () () (ly:make-dispatcher))
> 
> receiveFromChannel =
> #(define-music-function (chan) (ly:dispatcher?)
>#{
>  \applyContext
>  #(lambda (ctxt)
> (ly:connect-dispatchers
>  (ly:context-event-source ctxt)
>  chan))
>#})
> 
> sendToChannel =
> #(define-music-function (chan event-type) (ly:dispatcher? symbol?)
>   (define (event-proc ev)
>(ly:broadcast chan (ly:event-deep-copy ev)))
>   (define (context-proc ctxt)
>(ly:add-listener event-proc (ly:context-events-below ctxt) event-type))
>   #{ \applyContext #context-proc #})
> 
> piano_upper = {
>   c'4\p d' e' f'
>   g'1\mp
>   g'4\f f' e' d'
>   c'1
> }
> 
> piano_upper_II = {
>   c'4\ff\< d' e' f'
>   g'1\
>   g'4 f' e' d'
>   c'1
> }
> 
> piano_lower = {
>   \clef bass
>   c1
>   g,1
>   g,1
>   c1\ff
> }
> 
> myChannel = \newChannel
> myOtherChannel = \newChannel
> 
> \score {
>   <<
> \new PianoStaff <<
>   \new Staff \with {
> \sendToChannel \myChannel dynamic-event
> \omit DynamicText
>   } \piano_upper
>   \new Dynamics \with { \receiveFromChannel \myChannel } { 
> #(skip-of-length piano_upper) }
>   \new Staff \with {
> \sendToChannel \myChannel dynamic-event
> \omit DynamicText
>   } \piano_lower
> >>
> \new PianoStaff <<
>   \new Staff \with {
> \sendToChannel \myOtherChannel dynamic-event
> \sendToChannel \myOtherChannel span-dynamic-event
> \omit DynamicText
> \omit Hairpin
>   } \piano_upper_II
>   \new Dynamics \with { \receiveFromChannel \myOtherChannel } { 
> #(skip-of-length piano_upper) }
>   \new Staff \with {
> \receiveFromChannel \myOtherChannel
>   } \piano_lower
> >>
>   >>
> }
> 

Oh! Nice. This is really becoming a cool mechanism. Can’t wait to take it out 
for a real spin.

Thanks all!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Sending around contexts

[Kieren MacMillan]

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 95% of code that used to be managed 
with tags). I do hope there’s a non-tag-reliant mechanism for this feature.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Sending around contexts

[Valentin Petzel]

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
\version "2.22.0"

newChannel =
#(define-scheme-function (tag) (symbol?)
   (cons tag (ly:make-dispatcher)))

#(define (channel? chan)
   (and
(pair? chan)
(ly:dispatcher? (cdr chan
   

receiveFromChannel =
#(define-music-function (chan) (channel?)
#{
  \applyContext
  #(lambda (ctxt)
 (ly:connect-dispatchers
  (ly:context-event-source ctxt)
  (cdr chan)))
#})

sendToChannel =
#(define-music-function (chan event-type) (channel? symbol?)
   (define (event-proc ev)
(if (or (member 'send (ly:event-property ev 'tags)) (member (symbol-append 'send (car chan)) (ly:event-property ev 'tags)))
(begin
 (let* ((evc (ly:event-deep-copy ev)))
   (if (ly:event-property evc 'sentandremoved #f)
   (ly:event-set-property! evc 'tweaks (delete1! (cons 'stencil #f) (ly:event-property evc 'tweaks
   (ly:broadcast (cdr chan) evc)
   (if (and (not (ly:event-property ev 'sentandremoved #f)) (not (member 'sendkeep (ly:event-property ev 'tags
   (begin
 (ly:event-set-property! ev 'tweaks (cons (cons 'stencil #f) (ly:event-property ev 'tweaks)))
 (ly:event-set-property! ev 'sentandremoved #t)))
   (define (context-proc ctxt)
(ly:add-listener event-proc (ly:context-events-below ctxt) event-type))
   #{ \applyContext #context-proc #})

send = \tag #'send \etc
myChannel = \newChannel #'A
myChannelB = \newChannel #'B
myOtherChannel = \newChannel #'C
sendA = \tag #'sendA \etc
sendB = \tag #'sendB \etc
sendC = \tag #'sendC \etc
keep = \tag #'sendkeep \etc

piano_upper = {
   c'4\send\p d' e' f'
   g'1\mp
   g'4\sendB\keep\f f' e' d'
   c'1
}

piano_upper_II = {
   c'4\ff\send\< d' e' f'
   g'1\send\
   g'4 f' e' d'
   c'1
}

piano_lower = {
   \clef bass
   c1
   g,1
   g,1
   c1\sendA\ff
}

\score {
   <<
 \new PianoStaff <<
   \new Staff \with {
 \sendToChannel \myChannel dynamic-event
 \sendToChannel \myChannelB dynamic-event
   }  \piano_upper
   \new Dynamics \with { \receiveFromChannel \myChannel } { 
  #(skip-of-length piano_upper) }
   \new Staff \with {
 \sendToChannel \myChannel dynamic-event
 \sendToChannel \myChannelB dynamic-event
   } \piano_lower
   \new Dynamics \with { \receiveFromChannel \myChannelB } { 
  #(skip-of-length piano_upper) }
 >>
 \new PianoStaff <<
   \new Staff \with {
 \sendToChannel \myOtherChannel dynamic-event
 \sendToChannel \myOtherChannel span-dynamic-event
   } \piano_upper_II
   \new Dynamics \with { \receiveFromChannel \myOtherChannel } { 
  #(skip-of-length piano_upper) }
   \new Staff \new Voice \with {
 \receiveFromChannel \myOtherChannel
   } \piano_lower
 >>
   >>
}


signature.asc
Description: This is a digitally signed message part.