Re: Remote Ensemble Playing

[holl...@hollandhopson.com]

I second Jacktrip. I’ve also had success with JamKazam: 
https://www.jamkazam.com/ which is easier to setup. Using ethernet cables 
instead of wifi helps with latency and audio quality.

I recommend a Zoom meeting or similar to help everyone work out settings, audio 
inputs and outputs, etc.
Holland 

> On Mar 28, 2020, at 5:06 PM, Adam Good  wrote:
> 
> My friend in California and I (in Brooklyn, NY) had some pretty decent luck 
> with Jactrip:
> 
> https://ccrma.stanford.edu/software/jacktrip/ 
>  
> 
> Not the easiest to get set up and we need to try a few more times to 
> troubleshoot but, give it a try and please report back!
> 
> best,
> Adam
>  
> 
> On Sat, Mar 28, 2020 at 7:01 AM Peter Gentry 
>  > wrote:
> I appreciate this is off topic but in these times of social isolation does 
> anyone have any tips. Clearly latency is the main issue – I wonder could this 
> be reduced by say hosting a Zoom meeting on a private router – maybe only one 
> video for a conductor. Experience suggests that a latency of 25ms is not low 
> enough.
> 
> Regards Peter
> 
>  
> 

Re: Remote Ensemble Playing

[Adam Good]

My friend in California and I (in Brooklyn, NY) had some pretty decent luck
with Jactrip:

https://ccrma.stanford.edu/software/jacktrip/

Not the easiest to get set up and we need to try a few more times to
troubleshoot but, give it a try and please report back!

best,
Adam


On Sat, Mar 28, 2020 at 7:01 AM Peter Gentry <
peter.gen...@sunscales.myzen.co.uk> wrote:

> I appreciate this is off topic but in these times of social isolation does
> anyone have any tips. Clearly latency is the main issue – I wonder could
> this be reduced by say hosting a Zoom meeting on a private router – maybe
> only one video for a conductor. Experience suggests that a latency of 25ms
> is not low enough.
>
> Regards Peter
>
>
>

Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Noeck wrote
> You always show notes with the same pitch. It might
> make sense to look at slanted beams, too. But as there is no problem
> currently, I would not expect one due to the gap change.

Musically, two-note tremolos with twice the same note don't make any sense
at all, but for demonstrating the gap size behaviour, I nevertheless chose
these configurations.
And it was only by chance that I became aware of the unexpected gap size
implementation when experimenting with whole-note tremolos.


Noeck wrote
> Btw, how do you produce such a tremolo?
> I know these (depending on the notehead), but how to attach one beam and
> not the others?

These configurations with one beam attached came quite handy for the gap
comparisons (and you 
noticed the incorrect full beam in my example image, so it is good for
testing, too).

In your example, the black noteheads could be mistaken as quavers without
floating beams, but minims usually use full beams for tremolos.

But you can set the number of floating beams (i.e. gapped beams) using the
gap-count property:

%%
{
  \repeat tremolo 8 { e''32 f'' }
  \override Beam.gap-count = #1
  \repeat tremolo 8 { e''32 f'' }
  \override Beam.gap-count = #2
  \repeat tremolo 8 { e''32 f'' }
  \override Beam.gap-count = #3
  \repeat tremolo 8 { e''32 f'' }
}
%%

 

Cheers,
Torsten

tremolo-gap-count.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Remote Ensemble Playing

[antlists]

On 28/03/2020 18:55, Ralf Mattes wrote:

To the OP: there is an immanent latency in all network connections - packets 
need to
pass through switches and routers, and let's not forget the speed of electrical 
signals.
While one can get pretty low latency on local networks (Dante et al.) trying 
live jamming
over the internet is pretty much impossible.


Well, I shall soon find out ... a band I play for has scheduled a 
practice for Easter Saturday ...


Cheers,
Wol

Re: Remote Ensemble Playing

[Ralf Mattes]

Am Samstag, 28. März 2020 19:52 CET, Michael Gerdau  schrieb:

> Did they play live?

Looks (and sounds) like the all play to the same clicktrack 

 Cheers, RalfD

> And if so, what software/setup had been used?
> It doesn’t say so in the comments.
>
> Kind regards,
> Michael
>



--
Ralf Mattes

Hochschule für Musik Freiburg
Projektleitung HISinOne
Schwarzwaldstr. 141, D-79102 Freiburg
http://www.mh-freiburg.de

Re: Remote Ensemble Playing

[Ralf Mattes]

Am Samstag, 28. März 2020 19:37 CET, antlists  
schrieb:

> On 28/03/2020 11:00, Peter Gentry wrote:
> > I appreciate this is off topic but in these times of social isolation
> > does anyone have any tips. Clearly latency is the main issue – I wonder
> > could this be reduced by say hosting a Zoom meeting on a private router
> > – maybe only one video for a conductor. Experience suggests that a
> > latency of 25ms is not low enough.
> >
> > Regards Peter
> >
> https://www.youtube.com/watch?v=P0KiCXZ2IM0
>
> Stuff I've picked up elsewhere - avoid Firefox. I hate to say that, but
> the evidence is that one user on that and everyone else suffers.

It's not _that_ simple. This really depends on your video server software. Iff 
you
use a SFU then either Firefox will have to send more data (which is limited
by your upstream bandwidth which usually is much smaller than your downstream
bandwidth) our your other clients will get only one resolution/audio codec. But
that has little or nothing to do with latency. BTW, Firefox does have 
experimetal support
for Simulcast, you video solution just has to use it (many don't).
To the OP: there is an immanent latency in all network connections - packets 
need to
pass through switches and routers, and let's not forget the speed of electrical 
signals.
While one can get pretty low latency on local networks (Dante et al.) trying 
live jamming
over the internet is pretty much impossible.

 Cheers, RalfD

> Cheers,
> Wol
>



--
Ralf Mattes

Hochschule für Musik Freiburg
Projektleitung HISinOne
Schwarzwaldstr. 141, D-79102 Freiburg
http://www.mh-freiburg.de

Re: Remote Ensemble Playing

[Michael Gerdau]

Did they play live?
And if so, what software/setup had been used?
It doesn’t say so in the comments.

Kind regards,
Michael

Re: Proposal: Changing tremolo beam gap implementation

[Noeck]

Hi Torsten,

Am 28.03.20 um 16:55 schrieb Torsten Hämmerle:
> Only for non-zero gaps, the gap will start at the inside of stems

That sounds fine. You always show notes with the same pitch. It might
make sense to look at slanted beams, too. But as there is no problem
currently, I would not expect one due to the gap change.

Btw, how do you produce such a tremolo?
I know these (depending on the notehead), but how to attach one beam and
not the others?

{
  \repeat tremolo 2 { a'16 e'}
  \repeat tremolo 4 { a'16 e'}
}

Cheers,
Joram

Re: Remote Ensemble Playing

[antlists]

On 28/03/2020 11:00, Peter Gentry wrote:
I appreciate this is off topic but in these times of social isolation 
does anyone have any tips. Clearly latency is the main issue – I wonder 
could this be reduced by say hosting a Zoom meeting on a private router 
– maybe only one video for a conductor. Experience suggests that a 
latency of 25ms is not low enough.


Regards Peter


https://www.youtube.com/watch?v=P0KiCXZ2IM0

Stuff I've picked up elsewhere - avoid Firefox. I hate to say that, but 
the evidence is that one user on that and everyone else suffers.


Cheers,
Wol

Re: Minimal horizontal space for melismata

[Peter Crighton]

On Sat, 28 Mar 2020 at 09:34, Torsten Hämmerle 
wrote:

> For rhythmic alignment without noteheads, beams, accidentals, etc.
> consuming
> space, the relatively new
> *  NullVoice*
> has been invented.



This, however, still doesn't quite solve your problem yet as other elements
> still take up horizontal space.
>

Thanks, I wasn’t aware of NullVoice. This is better than what I had before,
but yes, it solves not every case.


> I've come to a solution that works with your example, but, I'll have to
> admit that if it had been "i -- met" instead of "a -- met", a tiny gap
> after
> the slim letter "i" still couldn't have been avoided that way.
>

In addition, longer melismata and note lengths lead to hyphens/gaps.

Now, I strangely wasn’t able to recreate it in the MWE, but in the
real-world score I’m working on including this snippet fixed it, even for
the shortest possible syllable “i”:
https://lists.gnu.org/archive/html/lilypond-user/2019-05/msg00389.html
There is a very minor drawback, in that the snippet adds a barely
noticeable space after a multisyllabic word. I opened a different thread
about this a few days ago, maybe a fix will be found.

--
Peter Crighton | Musician & Music Engraver based in Mainz, Germany
http://www.petercrighton.de

Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Noeck wrote
> I would also expect the "gap" to be the free space between stem and beam.

Hi Joram,

Thank you, then we seem to have a common understanding of "gap", even if the
current tremolo beam gap implementation behaves differently.



Noeck wrote
> In your attached image, I wonder if you have drawn the upper beam from
> the inner edge of the stem only for demonstration reasons, what a gap=0
> would be. The stems and beams have slightly rounded corners, haven't
> they? So if the beam touches the stem, it should overlap to avoid little
> notches where they touch.
> In other words, while currently gap=0 is a valid choice, with your
> proposed gap definition, gap should either be >0 or -stem-thickness but
> not 0, right?

Yes, you are right about the rounded corners, and even if a zero gap does
not make much sense, it should be handled in a reasonable way.
My example image was purely focusing on the size of the gap and wasn't fully
functional yet.

*Intended implementation*
The full-size stems will, as usual, run through from the very left to the
very right.
In the special case of gap = 0, the beams will also run completely through
the stems.
Only for non-zero gaps, the gap will start at the inside of stems so that
the effective free space will be as wide as the gap property suggests.

I've attached an example image showing gap = 0 and gap = 0.13 (i.e. the stem
width):

 

As you can see, a gap of 0 will not suffer from rounded beam corners, but a
gap > 0 will actually have the expected width.
In other words, if gap > 0, the shortened tremolo beam start will be shifted
by stem-width + gap compared to a standard stem. 

Cheers and thanks for the hint,
Torsten

tremolo-zero-gap.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: strange time changes - req help

[Aaron Hill]

On 2020-03-28 7:57 am, Malte Meyn wrote:

You don’t need this \partial 8*7. In fact it’s better to omit it for
correct autobeaming and bar checks. (Your code gives a bar check
warning.)


Odd, there should not be any bar check failures.

But I did not have access to my local LilyPond installation, so I had to 
use lilybin.com.  It does not show the program output unless there is an 
error.


Ignore my post then.


-- Aaron Hill

Re: Alignment issues of Time signature above the staff

[Kevin Barry]

Hi Chen,

I was able to solve the second of your problems (the whole bar rests
being shifted by the time signatures in the TimeSig context) by
adding:
\override TimeSignature.X-extent = ##f
(You could also use the value #'(0 . 0) if the warnings are off
putting, but I noticed that that doesn't *quite* fix it fully.)

I tried to reproduce your description of the first problem (time
signatures aligning over cue clefs), but even commenting out the
break-align-symbol override didn't make it appear. I was able to
correct the alignment of the first time signature by removing the
line:
\override TimeSignature.after-line-breaking = #shift-right-at-line-begin

After both of the above modifications everything looks OK to me, but
perhaps we need a fuller example.

Kevin

On Sat, 28 Mar 2020 at 10:30, Chen Leo  wrote:
>
> Hi, I am trying to put time signatures above the staffs according to 
> "http://lsr.dsi.unimi.it/LSR/Item?id=272;.
>
>
>
> I discovered an issue, that is whenever a clef change is made, the time 
> signature on the next bar fails to align to the bar line, it aligns to the 
> cue clef in the previous bar instead. After some research, I found out that 
> this is because the TimeSignature property "break-align-symbol" is set to 
> "##f". I set "break-align-symbol" back to "#'time-signature", and this 
> problem is solved, however, the horizontal alignments of the other time 
> signatures are messed up. (Using the code presented below, the 4/4 in the 
> first bar moves to the right & the bar rest on the third bar stretches to the 
> right. ) Are there any ways to align all the time signatures to their 
> corresponding bar lines without changing the alignments of other objects? 
> Thank you.
>
>
>
> \version "2.20.0"
>
>
>
> \layout {
>
>   \context {
>
> \type "Engraver_group"
>
> \consists "Time_signature_engraver"
>
> \consists "Axis_group_engraver"
>
> \name "TimeSig"
>
> \alias "Staff"
>
> \override TimeSignature.font-size = #4
>
> \override TimeSignature.break-align-symbol = #'time-signature
>
> \override TimeSignature.X-offset =
>
>   #ly:self-alignment-interface::x-aligned-on-self
>
> \override TimeSignature.self-alignment-X = #LEFT
>
> \override TimeSignature.after-line-breaking =
>
>   #shift-right-at-line-begin
>
>   }
>
>   \context {
>
> \Score
>
> \accepts TimeSig
>
>   }
>
>   \context {
>
> \Staff
>
> \remove "Time_signature_engraver"
>
>   }
>
> }
>
>
>
> timeSignatures = { \numericTimeSignature \time 4/4 s1 \time 3/8 s4. \time 3/4 
> s2. }
>
>
>
> \score {
>
>   <<
>
> \new TimeSig \timeSignatures
>
> \new Staff \relative c' { c4 ( d4 e4 f4 ) a4 ( g8 ) R2. }
>
> \new Staff \relative c' { R1 R4. \clef bass a2. }
>
> \new Staff \relative c' { R1 R4. R2. }
>
>   >>
>
> }
>
>

Re: strange time changes - req help

[Malte Meyn]

Am 28.03.20 um 15:30 schrieb Aaron Hill:


Would something like this work?


\version "2.20.0"

{
   \time 4/4
   \partial 8*7 | b'2 4. \bar "||"


You don’t need this \partial 8*7. In fact it’s better to omit it for 
correct autobeaming and bar checks. (Your code gives a bar check warning.)



   \time 6/8
   \partial 8 b'8 | b'4 8 8 8 8
   \partial 8*4 | b'4.~ 8 \bar "||"


Same for this \partial 8*4.


   \time 4/4
   \partial 4 b'4 | b'1
}

Re: Lilypond 2.20 on Mac 10.15

[Hans Åberg]

> On 28 Mar 2020, at 13:14, Moritz Heffter  wrote:
> 
>> https://stackoverflow.com/questions/18758837/xcode-quit-unexpectedly-for-my-project-not-in-xcode-4-6-3
> 
> But I found the following. In my my log files the issue occurs always with 
> the same dylib:  
> 85  libdyld.dylib 0x7fff6ede8cc9 start + 1
> 
> That might be a similar issue like the one discussed here: 
> https://github.com/sharkdp/bat/issues/680#issuecomment-553061780

There is s suggestion to run in Terminal:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
 -kill -r -domain local -domain system -domain user

on
  https://forums.developer.apple.com/thread/120530

It is related to Xcode crashing by some stray files from different versions.

Mentioned on this page, where they had same error as you, as a fix:
https://forums.developer.apple.com/thread/123855 

Re: strange time changes - req help

[Aaron Hill]

On 2020-03-28 6:27 am, Eby Mani wrote:

I'm trying to typeset some Victorian choral music with some strange
time changes that switch between. Attached samples.

e.g.
eg1, 4.5th beat of 4/4 time it goes to pickup bar (\partial 8) of 6/8 
time.
eg2, On the 5th beat of 6/8 time it goes to pickup bar(\partial 4) of 
4/4.


The time changes are for accompaniment interludes, no choral part is 
printed.


What are my options to typeset such music ?


Would something like this work?


\version "2.20.0"

{
  \time 4/4
  \partial 8*7 | b'2 4. \bar "||"
  \time 6/8
  \partial 8 b'8 | b'4 8 8 8 8
  \partial 8*4 | b'4.~ 8 \bar "||"
  \time 4/4
  \partial 4 b'4 | b'1
}



-- Aaron Hill

Re: Lilypond 2.20 on Mac 10.15

[Hans Åberg]

> On 28 Mar 2020, at 13:14, Moritz Heffter  wrote:
> 
>> https://stackoverflow.com/questions/18758837/xcode-quit-unexpectedly-for-my-project-not-in-xcode-4-6-3
> 
> But I found the following. In my my log files the issue occurs always with 
> the same dylib:  
> 85  libdyld.dylib 0x7fff6ede8cc9 start + 1
> 
> That might be a similar issue like the one discussed here: 
> https://github.com/sharkdp/bat/issues/680#issuecomment-553061780

On that page, they say this worked before starting the program:
  export DYLD_BIND_AT_LAUNCH=1

Re: Lilypond 2.20 on Mac 10.15

[Moritz Heffter]

>> On 27 Mar 2020, at 18:53, Moritz Heffter  wrote:
>> 
>>> Try in Terminal
>>> export PATH=/usr/bin:/bin:/usr/sbin:/sbin
>>> 
>>> and then
>>> /opt/lilypond/bin/lilypond
>> 
>> Hmm, I have done that, but unfortunately without progress.
> 
> In the link below, the issue was solved by fixing the environment variable 
> LIBRARY_SEARCH_PATHS. Have you set it? Type ‘env’ in Terminal, to make sure 
> it is not set there.

Thanks for the hint. My environment looks quite normal and it doesn’t contain 
any Library Search Paths.

> https://stackoverflow.com/questions/18758837/xcode-quit-unexpectedly-for-my-project-not-in-xcode-4-6-3

But I found the following. In my my log files the issue occurs always with the 
same dylib:  
85  libdyld.dylib   0x7fff6ede8cc9 start + 1

That might be a similar issue like the one discussed here: 
https://github.com/sharkdp/bat/issues/680#issuecomment-553061780

Best,
Moritz

Re: Proposal: Changing tremolo beam gap implementation

[Noeck]

Hi Torsten,

> *What do you think?*
> Wouldn't it be better to have "gap" actually mean "free space"?

I would also expect the "gap" to be the free space between stem and beam.

In your attached image, I wonder if you have drawn the upper beam from
the inner edge of the stem only for demonstration reasons, what a gap=0
would be. The stems and beams have slightly rounded corners, haven't
they? So if the beam touches the stem, it should overlap to avoid little
notches where they touch.
In other words, while currently gap=0 is a valid choice, with your
proposed gap definition, gap should either be >0 or -stem-thickness but
not 0, right?

{
  \override Beam.gap = 0.13  # roughly equivalent to free space = 0
  \repeat tremolo 4 { a32 e' }
}

Cheers,
Joram

Remote Ensemble Playing

[Peter Gentry]

I appreciate this is off topic but in these times of social isolation does
anyone have any tips. Clearly latency is the main issue - I wonder could
this be reduced by say hosting a Zoom meeting on a private router - maybe
only one video for a conductor. Experience suggests that a latency of 25ms
is not low enough.

Regards Peter

 

Alignment issues of Time signature above the staff

[Chen Leo]

Hi, I am trying to put time signatures above the staffs according to 
"http://lsr.dsi.unimi.it/LSR/Item?id=272;.



I discovered an issue, that is whenever a clef change is made, the time 
signature on the next bar fails to align to the bar line, it aligns to the cue 
clef in the previous bar instead. After some research, I found out that this is 
because the TimeSignature property "break-align-symbol" is set to "##f". I set 
"break-align-symbol" back to "#'time-signature", and this problem is solved, 
however, the horizontal alignments of the other time signatures are messed up. 
(Using the code presented below, the 4/4 in the first bar moves to the right & 
the bar rest on the third bar stretches to the right. ) Are there any ways to 
align all the time signatures to their corresponding bar lines without changing 
the alignments of other objects? Thank you.



\version "2.20.0"



\layout {

  \context {

\type "Engraver_group"

\consists "Time_signature_engraver"

\consists "Axis_group_engraver"

\name "TimeSig"

\alias "Staff"

\override TimeSignature.font-size = #4

\override TimeSignature.break-align-symbol = #'time-signature

\override TimeSignature.X-offset =

  #ly:self-alignment-interface::x-aligned-on-self

\override TimeSignature.self-alignment-X = #LEFT

\override TimeSignature.after-line-breaking =

  #shift-right-at-line-begin

  }

  \context {

\Score

\accepts TimeSig

  }

  \context {

\Staff

\remove "Time_signature_engraver"

  }

}



timeSignatures = { \numericTimeSignature \time 4/4 s1 \time 3/8 s4. \time 3/4 
s2. }



\score {

  <<

\new TimeSig \timeSignatures

\new Staff \relative c' { c4 ( d4 e4 f4 ) a4 ( g8 ) R2. }

\new Staff \relative c' { R1 R4. \clef bass a2. }

\new Staff \relative c' { R1 R4. R2. }

  >>

}

Re: Grace + repeat result in an extra error measure

[Aaron Hill]

On 2020-03-28 12:30 am, k.l. wrote:

<<\context Staff = "1" <<\relative g' { { c1 }\repeat volta 2 {
\appoggiatura g32 g8  ( [ f8 e8 f8 ] r2}}>> \context Staff 
= "2"

<< \relative e' {{  g1 }   \repeat volta 2 {  g1   }}
 
But

if single staff, no repeat or single measure, the result is right:





This seems to be related to issues where multiple staves need to share 
the same grace timing.


Adding \grace s32 to the second staff fixes the issue:


\version "2.18.2"

<<
  \context Staff = "1" <<
\relative g' {
  { c1 }
  \repeat volta 2 {
\appoggiatura g32
g8 [ f8 e8 f8 ] r2
  }
}
  >>
  \context Staff = "2" <<
\relative e' {
  { g1 }
  \repeat volta 2 {
\grace s32 % <==
g1
  }
}
  >>





-- Aaron Hill

Re: Minimal horizontal space for melismata

[Torsten Hämmerle]

Peter Crighton wrote
> Side question: Is there a shorter/nicer way to hide/omit all those things
> in the RhythmicStaff?

Hi Peter,

For rhythmic alignment without noteheads, beams, accidentals, etc. consuming
space, the relatively new
*  NullVoice*
has been invented.

This, however, still doesn't quite solve your problem yet as other elements
still take up horizontal space.

I've come to a solution that works with your example, but, I'll have to
admit that if it had been "i -- met" instead of "a -- met", a tiny gap after
the slim letter "i" still couldn't have been avoided that way.


In addition to using NullVoice, I've set proportionalNotationDuration on
Staff level to a high value to achieve narrow spacing.

And I've set ChordName.X-extent to zero.  There's the danger of overlapping
chord names, though.



\version "2.20.0"

Chords = \chordmode {
  f16*7 a16*3:m
}
Lyric = \lyricmode {
  Lo -- rem ip -- sum do -- lor sit a -- met.
}
Melody = {
  c16 c c c c c c c( a) a
}
<<
  \new ChordNames \chordmode {
\Chords
  }
  \new Lyrics
  \new RhythmicStaff {
\new NullVoice = "melody" {
  \Melody
}
  }
  \context Lyrics {
\lyricsto "melody" {
  \Lyric
}
  }
>>
\layout {
  \context {
\Score
proportionalNotationDuration = #(ly:make-moment 100)
  }
  \context {
\ChordNames
\override ChordName.X-extent = #'(0 . 0)
  }
  \context {
\Lyrics
\override LyricText.self-alignment-X = #LEFT
  }
  \context {
\RhythmicStaff
\override StaffSymbol.line-count = 0
\omit TimeSignature
\omit BarLine
  }
}


And that's how it looks like:
 


It's not perfect, but in rare cases with narrow one-character syllables, you
still might enter specific alternatives using \tag.

HTH,
Torsten

lorem-ipsum-narrow.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Grace + repeat result in an extra error measure

[k.l.]

<<\context Staff = "1" <<\relative g' { { c1 }\repeat volta 2 {   
\appoggiatura g32 g8  ( [ f8 e8 f8 ] r2}}>> \context Staff = "2"
<< \relative e' {{  g1 }   \repeat volta 2 {  g1   }}
 But
if single staff, no repeat or single measure, the result is right:
 
 
 



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html