Re: Markup for repeated notes or phrases

[Gilles THIBAULT]

> And let's say I want to add fingering instructions, but only to the
> first  , as if I had written
> 
> \relative c' { 8 8 8 8 8 8 8
> 8 }
> 

Sorry to answer so late.
This snippet can perhaps make your life easier :
  http://lsr.di.unimi.it/LSR/Item?id=768
But it will not work as you expect if you use \repeat. I often use a function 
like that, instead :
%--
nCopy = #(define-music-function (parser location n music)(integer? ly:music?)
(cond
  ((> n 1)(make-sequential-music 
(map (lambda (x)(ly:music-deep-copy music))
 (make-list n
  ((= n 1) music)
  (else (make-music 'Music 'void #t
%-

So the full code for you would be :

%--

\version "2.18.2"
\include "fingering.ly"
%% get this file at :
%%   http://gillesth.free.fr/Lilypond/fingering/fingering.ly
%% doc and tests here :
%%   http://gillesth.free.fr/Lilypond/fingering/

nCopy = #(define-music-function (parser location n music)(integer? ly:music?)
(cond
  ((> n 1)(make-sequential-music 
(map (lambda (x)(ly:music-deep-copy music))
 (make-list n
  ((= n 1) music)
  (else (make-music 'Music 'void #t

music = \nCopy #4 \relative c' { 8 8 }

\addFingering \music
  #"1324"

% RESULT =>
%  { 8 8 
%8 8 
%8 8 
%8  8 }

%--


DRAWBACKS : You have to use \relative *after* \nCopy :
Something like
  \relative c' {
  ...
  \nCopy #4 { c' d}
  ...
  }
will give you some strange results...
You may want either to  work in \absolute mode or to replace in the code of 
\nCopy, the string :
  (ly:music-deep-copy music)
by :
  (ly:music-deep-copy #{ \relative c' \music #})



-- 
Gilles

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Urs Liska]

Am 13.11.2015 um 10:57 schrieb Davide Liessi:
> 2015-11-13 6:02 GMT+01:00 Henning Hraban Ramm :
>> Why not combine the options? Use GitHub as long as it makes sense, but 
>> always keep a mirror on OLL server.
> That's my opinion, too: option a), plus mirroring the repositories at
> git.openlilylib.org.
>
>

It seems discussion settles towards this, so we'll go that route. With
regard to mirroring I think I'll do the following (please tell me if
someone has a better solution).

Create a Git repository on git.openlilylib.org's server (that is, a
local repository on the filesystem, not in the server's Gitlab
installation and have the Github repository as 'origin'.

Add a web hook on the Gitlab repo that triggers a script on the
openlilylib.org server. This script will fetch the updates from Github
and can optionally perform further tasks, e.g. build openLilyLib
documentation and deploy it.

As I don't want to require an http server kept running for this task I
would try to implement it in a way that the web server (Nginx) calls the
script when the Github web hook calls a certain URL. I don't know how to
do that yet but I assume it'll work similarly to calling up PHP stuff
through fastCGI.

###

One other thing to be discussed is the actual naming. As a prerequisite
I have significantly cleaned up the namespace below
https://github.com/openlilylib so that there are only three repositories
left. However, it's not clear how I should proceed now.

Currently we have the "openlilylib" repository which actually contains
two different things:

  * the original collection of "snippets" as started by Janek. These are
loosely organized and inconsistently documented LilyPond files
scattered in a number of directories.
  * A new, integrated approach for a library infrastructure, to be found
in the /ly directory in the repository. This contains a small number
of proof-of-concept (but also working) libraries. The new library
files are even less documented (only through source comments at the
maintainer's discretion) as designing a proper documentation system
is one of the most urgent issues that block any further development.

What we want to achieve is:

  * One repository with the core functionality of the new library
infrastructure (this contains the "API" against which libraries (or
user code) can work that Jan-Peter mentioned)
  * A number of library repositories.
The libraries that exist inside /ly, for example /ly/gridly or
/ly/scholarly, will be moved to repositories at this level. However,
I'm not sure if we should create an additional organization (e.g.
oll-libraries) for that to avoid cluttering the namespace and
website dashboard with potentially numerous libraries and other,
independent project repos.
BTW: This disentangling implies that *anyone* can create a new
library for use with openLilyLib and host it *anywhere*. This will
be so much better than the current approach of having the libraries
maintained *inside* one single repository.
  * The current repository, maybe renamed.

This set-up will have the big advantage that we can keep the existing
repository so no user code will break. Whenever something is moved to
the new structure we can make the current functions issue a deprecation
warning, telling the user where the new functionality should be taken
from (I have already done this several times and provided some helper
functions).
An implication and additional advantage is that we can keep the existing
repository as a collection of loosely related code (as Janek intended: a
git-managed and lily-version-agnostic LSR)

I suggest (and if noone objects will do it)

  * renaming the "openlilylib" repository to "snippets"
-> https://github.com/openlilylib/snippets
NOTE: This may require users to adapt their repository set-ups and
LilyPond include path settings
  * creating a new repository
https://github.com/openlilylib/oll-core
where the stuff from /ly/_internal will be moved (reviewing a number
of things along the way)


Regaring the location of the individual libraries, what would you
consider best:

  * adding all beside oll-core
(keeping the option that anyone creates libraries in their own place)
  * creating a new openlilylib sibling organization for that purpose
  * Just have library maintainers maintain their repos in their own
namespace
(providing a central listing of available libraries in some place,
of course)


Best
Urs



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Simon Albrecht]

Hello Urs,

I think this makes a very sound and nice impression. Go ahead!

Thanks, Simon

On 13.11.2015 11:58, Urs Liska wrote:



Am 13.11.2015 um 10:57 schrieb Davide Liessi:

2015-11-13 6:02 GMT+01:00 Henning Hraban Ramm:

Why not combine the options? Use GitHub as long as it makes sense, but always 
keep a mirror on OLL server.

That's my opinion, too: option a), plus mirroring the repositories at
git.openlilylib.org.




It seems discussion settles towards this, so we'll go that route. With 
regard to mirroring I think I'll do the following (please tell me if 
someone has a better solution).


Create a Git repository on git.openlilylib.org's server (that is, a 
local repository on the filesystem, not in the server's Gitlab 
installation and have the Github repository as 'origin'.


Add a web hook on the Gitlab repo that triggers a script on the 
openlilylib.org server. This script will fetch the updates from Github 
and can optionally perform further tasks, e.g. build openLilyLib 
documentation and deploy it.


As I don't want to require an http server kept running for this task I 
would try to implement it in a way that the web server (Nginx) calls 
the script when the Github web hook calls a certain URL. I don't know 
how to do that yet but I assume it'll work similarly to calling up PHP 
stuff through fastCGI.


###

One other thing to be discussed is the actual naming. As a 
prerequisite I have significantly cleaned up the namespace below 
https://github.com/openlilylib so that there are only three 
repositories left. However, it's not clear how I should proceed now.


Currently we have the "openlilylib" repository which actually contains 
two different things:


  * the original collection of "snippets" as started by Janek. These
are loosely organized and inconsistently documented LilyPond files
scattered in a number of directories.
  * A new, integrated approach for a library infrastructure, to be
found in the /ly directory in the repository. This contains a
small number of proof-of-concept (but also working) libraries. The
new library files are even less documented (only through source
comments at the maintainer's discretion) as designing a proper
documentation system is one of the most urgent issues that block
any further development.

What we want to achieve is:

  * One repository with the core functionality of the new library
infrastructure (this contains the "API" against which libraries
(or user code) can work that Jan-Peter mentioned)
  * A number of library repositories.
The libraries that exist inside /ly, for example /ly/gridly or
/ly/scholarly, will be moved to repositories at this level.
However, I'm not sure if we should create an additional
organization (e.g. oll-libraries) for that to avoid cluttering the
namespace and website dashboard with potentially numerous
libraries and other, independent project repos.
BTW: This disentangling implies that *anyone* can create a new
library for use with openLilyLib and host it *anywhere*. This will
be so much better than the current approach of having the
libraries maintained *inside* one single repository.
  * The current repository, maybe renamed.

This set-up will have the big advantage that we can keep the existing 
repository so no user code will break. Whenever something is moved to 
the new structure we can make the current functions issue a 
deprecation warning, telling the user where the new functionality 
should be taken from (I have already done this several times and 
provided some helper functions).
An implication and additional advantage is that we can keep the 
existing repository as a collection of loosely related code (as Janek 
intended: a git-managed and lily-version-agnostic LSR)


I suggest (and if noone objects will do it)

  * renaming the "openlilylib" repository to "snippets"
-> https://github.com/openlilylib/snippets
NOTE: This may require users to adapt their repository set-ups and
LilyPond include path settings
  * creating a new repository
https://github.com/openlilylib/oll-core
where the stuff from /ly/_internal will be moved (reviewing a
number of things along the way)


Regaring the location of the individual libraries, what would you 
consider best:


  * adding all beside oll-core
(keeping the option that anyone creates libraries in their own place)
  * creating a new openlilylib sibling organization for that purpose
  * Just have library maintainers maintain their repos in their own
namespace
(providing a central listing of available libraries in some place,
of course)


Best
Urs





___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



___
lilypond-user mailing list
lilypond-user@gnu.org

Re: Markup for repeated notes or phrases

[David Kastrup]

Gilles THIBAULT  writes:

>> And let's say I want to add fingering instructions, but only to the
>> first  , as if I had written
>> 
>> \relative c' { 8 8 8 8 8 8 8
>> 8 }
>> 
>
> Sorry to answer so late.
> This snippet can perhaps make your life easier :
>   http://lsr.di.unimi.it/LSR/Item?id=768
> But it will not work as you expect if you use \repeat. I often use a function 
> like that, instead :
> %--
> nCopy = #(define-music-function (parser location n music)(integer? ly:music?)
> (cond
>   ((> n 1)(make-sequential-music 
> (map (lambda (x)(ly:music-deep-copy music))
>  (make-list n
(ly:music-deep-copy (make-sequential-music (make-list n music)))

will work fine I think.

However, it will not likely work well in \relative mode, so you probably
should write

  (make-relative (music) music
(ly:music-deep-copy (make-sequential-music (make-list n music

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Tuplets spaced unevenly

[Noeck]

Hi Javier,

this has been solved in some 2.19 version. In 2.19.21 the tuplets are
evenly spaced. Can you upgrade?

Cheers,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Matteo Ceccarello]

I also vote for option a, and I agree with the comments of Sharon on 
option c.


Cheers,
Matteo

On 12/11/2015 23:22, ciconia wrote:

But there are also drawbacks to c) because it is hosted on my own (well,

hosted in a data center) server:

- I can guarantee availability to a lesser extent than a big service
provider
- I can't guarantee not to break things or lose everything due to
misconfiguration
- I can't guarantee that I will always have that kind of server or that
I'll even be around in the LilyPond community.
- I don't know if there's a smooth transfer path if the latter should
happen.

Therefore I'd like to ask around what you consider an appropriate
approach.

Exactly those drawbacks, and a some more:

- People would have to register on your site in order contribute, while at
least a substantial part of them are already on github.
- Github is also kind of the place to hang among younger developers, so you
risk losing that crowd if you wish to attract them to contribute.
- What about backup?

If your basic motive is reorganising the code, I think you don't really gain
anything from moving it away from github to your own server. Let's put it
like this, I'm sure you'd rather be coding than maintaining your gitlab
installation.

I say go with option a. You could use the existing github organisation and
just add repositories to it.

best
Sharon



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/RFC-new-location-for-openLilyLib-repository-tp183476p183484.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Tempo equivalence markup

[Jacques Menu]

Hello Robert,

I use the following, but I don’t know how to add the arrows:


\version "2.19.30"

\relative {
  \clef "bass"
  \key c \major
  \numericTimeSignature\time 4/4

  \tempo \markup {
\concat {
  "le double plus lent "
  \smaller \general-align #Y #DOWN \note #"4" #1 " = "
  \smaller \general-align #Y #DOWN \note #"2" #1
  " précédente = 104"
}
  }

  r4 ^\markup{\bold "solo"} r8 e8 -\markup{\italic "doux" \dynamic "mf"} ( 
\acciaccatura {
g8
  } f8 [ e8 ) ] r8 e8 ( | % 163
  \acciaccatura {
g8
  } f8 [ e8 ) ] r8 e8 ( \acciaccatura { g8 } f8 [ e8 ) ] \acciaccatura { g8 } 
f8 [ ( e8 )
  ] | % 164
  \acciaccatura { g8 } f8 ( [ e8 ) ~ ] e4 r2 \break | % 165
}



> Le 13 nov. 2015 à 08:51, Robert Schmaus  a écrit :
> 
> I've done something similar using an ossia staff some time ago. That's 
> definitely a way. 
> 
> My solution (which was for drums) looked like this (I can't tell you right 
> now, where I got the arrowed slur commands from - but that's probably easy to 
> find):
> 
> FullDrums = <<
> 
> \new DrumStaff = "main" <<
> 
> \new DrumVoice { \voiceOne \DrumsUp }
> \new DrumVoice { \voiceTwo \DrumsDown }
> 
> >>
> {
> 
> \new DrumStaff \with {
> alignBelowContext = "main"
> \remove Time_signature_engraver
> \remove Clef_engraver
> \remove Bar_number_engraver
> \remove Bar_engraver
> \override StaffSymbol.line-count = #0
> fontSize = #-4
> \override StaffSymbol.staff-space = #(magstep -3)
> \override StaffSymbol.thickness = #(magstep -3)
> }
> {
> \new DrumVoice \drummode {
> 
> s1 * 2
> s2
> 
> \arrowed-slur-outside-staff
> \slurDown
> s2. \tuplet 3/2 { sn8 sn sn ( }
> \noBreak
> sn8[ ) sn sn] \stopStaff
> }
> }
> }
> 
> >>
> 
> That is of course not compilable - just to show how I did it ...
> 
> Best, Robert 
> 
> 
> __
> 
> Truth does not change according to our ability to stomach it.
> -- Flannery O'Connor
> 
> On 13 Nov 2015, at 06:34, Andrew Bernard  > wrote:
> 
>> The attached image shows a tempo equivalence markup I need to set, 
>> indicating that a 32 in the context of the preceding 5/4 tuplets now equals 
>> a 16. The partial tuplet bracket seems complicated to do, and I don’t really 
>> know how to set this fragment of combined partial music and text. The matter 
>> is complicated by the fact that I use a custom music font, and worse still 
>> (!) with notehead glyphs that are specially customised also to achieve the 
>> very precise appearance the composer requires. So just using \note and so on 
>> is not what I need. Would this be best done as a type of ossia?
>> 
>> Any help appreciated.
>> 
>> 
>> Andrew
>> 
>> 
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/lilypond-user 
>> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Tuplets spaced unevenly

[Simon Albrecht]

On 13.11.2015 09:40, Urs Liska wrote:


Am 13.11.2015 um 09:11 schrieb Noeck:

Hi Javier,

this has been solved in some 2.19 version. In 2.19.21 the tuplets are
evenly spaced. Can you upgrade?

In case you *have* to use 2.18 there's a workaround by restarting a
spacing section. I don't have the command available but you can first
try looking that up in the manual.


\newSpacingSection

HTH, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Tuplets spaced unevenly

[Urs Liska]

Am 13.11.2015 um 09:11 schrieb Noeck:
> Hi Javier,
>
> this has been solved in some 2.19 version. In 2.19.21 the tuplets are
> evenly spaced. Can you upgrade?

In case you *have* to use 2.18 there's a workaround by restarting a
spacing section. I don't have the command available but you can first
try looking that up in the manual.

HTH
Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Combined marks (rehearsal mark, fermata) + break

[Xavier Scheuer]

On 13 November 2015 at 06:47, Jay Anderson  wrote:
>
> I know I can do this to combine marks:
>
>   \mark \markup { \override #'(baseline-skip . 3) \center-column {
> \line { \box \bold "P" }
> \line { \musicglyph #"scripts.ufermata" }
>   } }
>
> This produces a rehearsal mark over a fermata over a bar line. However
> when this occurs at a line break I want the fermata over the barline
> before the break and the rehearsal mark at the beginning of the line
> after the break. Is there a good way to do this currently? (the
> lilypond web site appears unreachable again so I haven't done my
> usually scouring there.)

Hi,

Federico asked almost the same question a few days ago.
I would personally suggest to use Neil's "multi-mark-engraver".
See http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00235.html


> If there's not a good way to do this today, one feature that I think
> would solve this cleanly is adding a fermata barline type. So the
> above would be:
>
> \bar "(|"
> \mark \markup { \box \bold "P" }
>
> Where '(' in the bar means a fermata above the bar. We could include
> "(|", "|)", and "(|)" for fermatas above, below, and above and below
> (and of course variations with different actual bar types). What do
> you think? Is it too strange to put this as part of the bar line?

It is possible to have fermatas both above and below the barline using
Neil's "multi-mark-engraver" (one with #'direction = #UP and the other
one #DOWN).

Fermatas as part as the barline? I do not know, maybe, why not.

Cheers,
Xavier

-- 
Xavier Scheuer 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Davide Liessi]

2015-11-13 6:02 GMT+01:00 Henning Hraban Ramm :
> Why not combine the options? Use GitHub as long as it makes sense, but always 
> keep a mirror on OLL server.

That's my opinion, too: option a), plus mirroring the repositories at
git.openlilylib.org.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Simon Albrecht]

On 13.11.2015 15:49, Urs Liska wrote:
(note: this will make it possible to create private/project/house 
repositories that take advantage of the openLilyLib infrastructure)


Will this also be possible for repositories hosted outside GitHub (e.g. 
with BitBucket?)


~Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Federico Bruni]

Il giorno ven 13 nov 2015 alle 11:58, Urs Liska  ha 
scritto:

I suggest (and if noone objects will do it)
renaming the "openlilylib" repository to "snippets"
-> https://github.com/openlilylib/snippets
NOTE: This may require users to adapt their repository set-ups and 
LilyPond include path settings

creating a new repository
https://github.com/openlilylib/oll-core
where the stuff from /ly/_internal will be moved (reviewing a number 
of things along the way)


Regaring the location of the individual libraries, what would you 
consider best:

adding all beside oll-core
(keeping the option that anyone creates libraries in their own place)
creating a new openlilylib sibling organization for that purpose
Just have library maintainers maintain their repos in their own 
namespace
(providing a central listing of available libraries in some place, of 
course)


I would avoid confusion and keep a single organization.

The first option is the best IMO. I don't see the benefit of keeping 
the libraries in separate places. Libraries are the core content of 
openlilylib, not an additional feature (like e.g. an editor plugin). 
It's all plain text files, the size of the repository won't be big.





___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Testing requested: new manuscript viewer tool for Frescobaldi

[Urs Liska]

Am 13.11.2015 um 17:22 schrieb Federico Bruni:
> Il giorno ven 13 nov 2015 alle 16:11, tapani  ha
> scritto:
>> Is there any way of getting this without running Frescobaldi from the
>> Git
>> repository? I run Frescobaldin in Linux, from installation files of the
>> latest stable version.
>
> I suggest using Git and clone frescobaldi and python-ly.
> All you have to is changing your frescobaldi.desktop file. Find
> attached what I'm using on my computer (I keep the git repositories
> under ~/src).
> The file should be saved in ~/.local/share/applications/

Probably adding python-ly to the PYTHONPATH environment variable, e.g.
in ~/.bashrc

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Urs Liska]

Am 13.11.2015 um 16:48 schrieb Simon Albrecht:
> On 13.11.2015 15:49, Urs Liska wrote:
>> (note: this will make it possible to create private/project/house
>> repositories that take advantage of the openLilyLib infrastructure)
>
> Will this also be possible for repositories hosted outside GitHub
> (e.g. with BitBucket?)
>
> ~Simon

Of course. As long as you are not intending to register a library with
openLilyLib the only "connection" that exists is that between your local
directory (doesn't even have to be a Git repository ...), the oll-core
library and LilyPond's include path.

And when you want to register a library with openLilyLib all we'll need
is an URL where we can fetch from, so BitBucket or any private (but
accessible) remote Git repository will work :-)

Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Testing requested: new manuscript viewer tool for Frescobaldi

[Federico Bruni]

Il giorno ven 13 nov 2015 alle 16:11, tapani  ha 
scritto:
Is there any way of getting this without running Frescobaldi from the 
Git
repository? I run Frescobaldin in Linux, from installation files of 
the

latest stable version.


I suggest using Git and clone frescobaldi and python-ly.
All you have to is changing your frescobaldi.desktop file. Find 
attached what I'm using on my computer (I keep the git repositories 
under ~/src).

The file should be saved in ~/.local/share/applications/




frescobaldi.desktop
Description: application/desktop
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Important notice for openLilyLib users and contributors

[Urs Liska]

For anyone using or contributing to openLilyLib: I have done a few
modifications that may affect your work:

I have renamed the openlilylib/openlilylib repository to
openlilylib/snippets and created a full copy (--mirror) of it at the old
location openlilylib/openlilylib.

Both repositories have identical content right now, but the Issue
tracker and pull requests have effectively moved to the "snippets" location.

This means:

a) you are a *user* of openLilyLib, having *cloned*  the repository:

- you *can* continue to use your local copy as usual but you won't get
any updates
- but instead please point your repository to use the new location as
soon as possible.
  If you are not sure how to proceed please post the output of `git
remote -v` (from inside the repository)
- If you need to open issues you have to do that in 'snippets' (issues
are deactivated for 'openlilylib')


b) you are a *contributor* to openLilyLib:

- please change the URL of your 'origin' or 'upstream' remote to
g...@github.com:openlilylib/snippets.git (or the respective HTTPS URL)
- if you have a fork please check where this now refers to as the
upstream repository.
- Push any commits *exclusively* to and open Pull Requests against the
'snippets' repository

I hope this doesn't cause any confusion.

Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Testing requested: new manuscript viewer tool for Frescobaldi

[tapani]

Is there any way of getting this without running Frescobaldi from the Git
repository? I run Frescobaldin in Linux, from installation files of the
latest stable version.
Tapani



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Testing-requested-new-manuscript-viewer-tool-for-Frescobaldi-tp178737p183515.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Testing requested: new manuscript viewer tool for Frescobaldi

[Urs Liska]

Am 13. November 2015 16:11:54 MEZ, schrieb tapani :
>Is there any way of getting this without running Frescobaldi from the
>Git
>repository? I run Frescobaldin in Linux, from installation files of the
>latest stable version.
>Tapani

I don't think so.

But running Frescobaldi from git should be easy on Linux.
>
>
>
>--
>View this message in context:
>http://lilypond.1069038.n5.nabble.com/Testing-requested-new-manuscript-viewer-tool-for-Frescobaldi-tp178737p183515.html
>Sent from the User mailing list archive at Nabble.com.
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Testing requested: new manuscript viewer tool for Frescobaldi

[MarcM]

Awesome. Does both the manuscript view and the lilypond preview view scroll
simultaneously ?
 



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Testing-requested-new-manuscript-viewer-tool-for-Frescobaldi-tp178737p183523.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Testing requested: new manuscript viewer tool for Frescobaldi

[Urs Liska]

Am 13.11.2015 um 18:41 schrieb MarcM:
> Awesome. Does both the manuscript view and the lilypond preview view scroll
> simultaneously ?
>  


Well, it is a loong way to go but the long-term goal is that they scroll
simultaneously, yes.
The user has of course to mark up the manuscript so Frescobaldi can know
where the measures are.

Basically the manuscript should always "be" in the measure that is
currently edited.

And it will be able to maintain different manuscripts to display the
"current" measure in the different
sources.


Phew. One day, that is ...













___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Simon Albrecht]

On 13.11.2015 17:19, Federico Bruni wrote:
Il giorno ven 13 nov 2015 alle 11:58, Urs Liska  
ha scritto:

I suggest (and if noone objects will do it)
renaming the "openlilylib" repository to "snippets"
-> https://github.com/openlilylib/snippets
NOTE: This may require users to adapt their repository set-ups and 
LilyPond include path settings

creating a new repository
https://github.com/openlilylib/oll-core
where the stuff from /ly/_internal will be moved (reviewing a number 
of things along the way)


Regaring the location of the individual libraries, what would you 
consider best:

adding all beside oll-core
(keeping the option that anyone creates libraries in their own place)
creating a new openlilylib sibling organization for that purpose
Just have library maintainers maintain their repos in their own 
namespace
(providing a central listing of available libraries in some place, of 
course)


I would avoid confusion and keep a single organization.

The first option is the best IMO. I don't see the benefit of keeping 
the libraries in separate places. Libraries are the core content of 
openlilylib, not an additional feature (like e.g. an editor plugin).


The idea behind the new setup would be that the only ‘core’ content of 
openlilylib is some basic infrastructure, such as is contained in 
/ly/_internal. Every library can be used independently and arbitrarily, 
so they don’t make up any ‘core’.



It's all plain text files, the size of the repository won't be big.


Well, the memory size has never been the point, I think. It’s rather the 
difficulty of maintaining and managing a potentially great number of 
libraries, if e.g. everybody with push access to any of the libraries 
can push to all the other libraries too.


Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Very important and very urgent question...

[Blöchl Bernhard]

If you prepare real Turkish classical music with 53 divisions of the 
octave, may be you can find some useful at

http://lilypond.org/doc/v2.18/Documentation/notation/turkish-classical-music

Am 13.11.2015 20:28, schrieb Blöchl Bernhard:

Have a look at
http://lilypond.org/doc/v2.18/Documentation/notation/arabic-music
There arte some different methods of notation. The lilypond way with
the mirrored b, closely associated with the Turkish tradition. Another
common one uses a slashed b for the half flat.
I do not lnow the meaning of the b square in your examples?



Am 13.11.2015 20:02, schrieb Server Acim:

Dear LilyPond User List Members,

Hello.

I have some questions..
I had given some links below. These links are Turkish folk music
notes. As well as you will see there is a flat sign and 2 number.

This sign has a place in SMUFL with Turkish folk music accidentals
(U+E450 – U+E45F). Its full description is "U+E455,
accidental2CommaFlat,
2-comma flat".

But, the question is how can I use this sign while I am building a
Turkish Folk Song in LilyPond.

http://www.smufl.org/version/latest/range/turkishFolkMusicAccidentals/

I am preparing new Folk Song adaptation from Arguvan Region of Malatya
city of Turkey. There should be only a this sign in "key signature"
place. I even don't have to include the "makam.ly" file.

I am inserting down the links of other notation examples from Turkish
Folk Music repertoire.

http://notaarsivleri.com/thmnotalar/00979.png
http://notaarsivleri.com/thmnotalar/01831.png
http://notaarsivleri.com/thmnotalar/00771.png
http://notaarsivleri.com/thmnotalar/03644.png

I just need to insert this sign as key signature into the LilyPond
file. And other "koma-sound / mikro-sound" sign is not needed to
insert into anywhere in the piece.

===
The other question is, how can I create this gylph with scheme. From
where do I have to start? As a second plan...

With my respects.

Bye.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Very important and very urgent question...

[Server Acim]

Dear LilyPond User List Members,

Hello.

I have some questions..
I had given some links below. These links are Turkish folk music notes. 
As well as you will see there is a flat sign and 2 number.


This sign has a place in SMUFL with Turkish folk music accidentals 
(U+E450 – U+E45F). Its full description is "U+E455, accidental2CommaFlat,

2-comma flat".

But, the question is how can I use this sign while I am building a 
Turkish Folk Song in LilyPond.


http://www.smufl.org/version/latest/range/turkishFolkMusicAccidentals/

I am preparing new Folk Song adaptation from Arguvan Region of Malatya 
city of Turkey. There should be only a this sign in "key signature" 
place. I even don't have to include the "makam.ly" file.


I am inserting down the links of other notation examples from Turkish 
Folk Music repertoire.


http://notaarsivleri.com/thmnotalar/00979.png
http://notaarsivleri.com/thmnotalar/01831.png
http://notaarsivleri.com/thmnotalar/00771.png
http://notaarsivleri.com/thmnotalar/03644.png

I just need to insert this sign as key signature into the LilyPond file. 
And other "koma-sound / mikro-sound" sign is not needed to insert into 
anywhere in the piece.


===
The other question is, how can I create this gylph with scheme. From 
where do I have to start? As a second plan...


With my respects.

Bye.
--
Server ACİM
- Besteci (Composer)
- İnönü Üniversitesi Öğretim Üyesi (Full Professor of Music Composition 
at Inonu Universitesi - Malatya - TURKEY)

- Linux Mint Kullanıcısı ve Destekçisi (Linux Mint User and Supporter)

http://google.com/+AcimNameTr
http://about.me/server.acim

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Test1

[Server Acim]

Test1
--
Server ACİM
- Besteci (Composer)
- İnönü Üniversitesi Öğretim Üyesi (Full Professor of Music Composition 
at Inonu Universitesi - Malatya - TURKEY)

- Linux Mint Kullanıcısı ve Destekçisi (Linux Mint User and Supporter)

http://google.com/+AcimNameTr
http://about.me/server.acim

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Very important and very urgent question...

[Blöchl Bernhard]

Have a look at
http://lilypond.org/doc/v2.18/Documentation/notation/arabic-music
There arte some different methods of notation. The lilypond way with the 
mirrored b, closely associated with the Turkish tradition. Another 
common one uses a slashed b for the half flat.

I do not lnow the meaning of the b square in your examples?



Am 13.11.2015 20:02, schrieb Server Acim:

Dear LilyPond User List Members,

Hello.

I have some questions..
I had given some links below. These links are Turkish folk music
notes. As well as you will see there is a flat sign and 2 number.

This sign has a place in SMUFL with Turkish folk music accidentals
(U+E450 – U+E45F). Its full description is "U+E455,
accidental2CommaFlat,
2-comma flat".

But, the question is how can I use this sign while I am building a
Turkish Folk Song in LilyPond.

http://www.smufl.org/version/latest/range/turkishFolkMusicAccidentals/

I am preparing new Folk Song adaptation from Arguvan Region of Malatya
city of Turkey. There should be only a this sign in "key signature"
place. I even don't have to include the "makam.ly" file.

I am inserting down the links of other notation examples from Turkish
Folk Music repertoire.

http://notaarsivleri.com/thmnotalar/00979.png
http://notaarsivleri.com/thmnotalar/01831.png
http://notaarsivleri.com/thmnotalar/00771.png
http://notaarsivleri.com/thmnotalar/03644.png

I just need to insert this sign as key signature into the LilyPond
file. And other "koma-sound / mikro-sound" sign is not needed to
insert into anywhere in the piece.

===
The other question is, how can I create this gylph with scheme. From
where do I have to start? As a second plan...

With my respects.

Bye.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Gounod - Le Rendez Vous

[tisimst]

Alberto,

On Thu, Nov 12, 2015 at 10:54 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n183480...@n5.nabble.com> wrote:

On 12.11.2015 16:52, Alberto Simões wrote:
>
> > Hello, Simon!
> >
> > On 12/11/15 11:21, Simon Albrecht wrote:
> >>
> >> Two annotations:
> >> – Sometimes it would be nice to have whiteout for DynamicTextSpanner
> >> against SpanBar; I don’t quite know the best way to do it, though.
> >> Perhaps you could use \markup\whiteout-box on the individual text bits?
> >
> > I didn't understand it very well. You are saying the text from
> > crescendo/decrescendo and the -- -- are too close?
>
> No, I meant overlaps as in valse 1, m. 39/40. The following works fine:
> 
> \version "2.19.31"
> \new PianoStaff <<
>\new Staff {
>  \partial 8
>  8-\tweak bound-details.left.text \markup\whiteout "cresc." \cresc
>  4 4 4\!
>}
>\new Staff {
>  8
>  4 4 4
>}
>  >>
> %%%
> In 2.19.32, it will be possible to specify padding in whiteout-box (as
> of issue 4504). That will be preferable then, but for now
> whiteout-outline is just fine. (try \whiteout-box instead of \whiteout
> to test)


I've finally gotten around to looking at the score in more detail and here
are a few more things I've found to improve things:

1. In addition to Simon's suggestions for improving the appearance of the
dynamics when clashing with barlines, a couple of other options are to
choose between the general

\override DynamicTextSpanner.whiteout-box = #3

or changing each individual text (where necessary) to

\markup { \override #'(thickness . 3) \whiteout-box \italic "TEXT" }

Those two settings seemed to work really well on my computer. I found that
\whiteout-box gave more reliable results than \whiteout.

2. Valse 1 m.58 beat 2, f in chord should be fis

3. Valse 3 m.47 move the dynamic "f" left so staves can be closer together
using \once \override DynamicText.X-offset = #-2 just before the note it is
linked to.

That's about all for now. Hope that helps.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Gounod-Le-Rendez-Vous-tp183419p183534.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Can I vary the system width for 1 system only

[Robin Bannister]

Peter Berlau wrote:


I found a ugly solution
with
\stopStaffs % generates 2 invisible staffs
s1
s1
\startStaff
for this i have to add on same place in the
\chords  also 2
s1
s1
to adjust chords to the remaining bars


In this case you already have a structure amenable to splitting:
 - 34 bars melody
 - 2*4 bars coda
So you could have melody variable and a coda variable,
and introduce a third variable for the gap;
eg it would then be easy to omit the gap from midi.


But I agree that involving s1 is a depressing sort of hack.


See if you like the attached pauseStaffBL hack any better.
No skips needed - it maltreats bar lines instead.
The demo does '\pauseStaffBL 40 \break' at the end of measure 9.


Cheers,
Robin

\version "2.18.0"

pauseStaffBL = 
#(define-music-function (parser location white-width) (number?)
  (define (append-whitebox grob) 
(let* (
  (stil (ly:bar-line::print grob))
  (yext (ly:stencil-extent stil 1))
  (y-padding 0.2)
  (box-height (interval-widen yext y-padding))
  (box-width (cons 0 white-width)) 
  (box-stil (make-filled-box-stencil box-width box-height))
  (whitebox-stil (stencil-with-color box-stil white
)))
 (ly:stencil-combine-at-edge stil X RIGHT whitebox-stil 0)))
  #{
\once \override Score.BarLine.stencil = #append-whitebox 
\once \override Score.BarLine.layer = 1 % mask StaffSymbol
  #})  


pauseStaffBL.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Some questions about a problem.

[Server Acim]

Dear LilyPond User List Members,

Hello.

I have some questions..
I had given some links below. These links are Turkish folk music notes. 
As well as you will see there is a flat sign and 2 number.


This sign has a place in SMUFL with Turkish folk music accidentals 
(U+E450 – U+E45F). Its full description is "U+E455, accidental2CommaFlat,

2-comma flat".

But, the question is how can I use this sign while I am building a 
Turkish Folk Song in LilyPond.


http://www.smufl.org/version/latest/range/turkishFolkMusicAccidentals/

I am preparing new Folk Song adaptation from Arguvan Region of Malatya 
city of Turkey. There should be only a this sign in "key signature" 
place. I even don't have to include the "makam.ly" file.


I am inserting down the links of other notation examples from Turkish 
Folk Music repertoire.


http://notaarsivleri.com/thmnotalar/00979.png
http://notaarsivleri.com/thmnotalar/01831.png
http://notaarsivleri.com/thmnotalar/00771.png
http://notaarsivleri.com/thmnotalar/03644.png

I just need to insert this sign as key signature into the LilyPond file. 
And other "koma-sound / mikro-sound" sign is not needed to insert into 
anywhere in the piece.


===
The other question is, how can I create this gylph with scheme. From 
where do I have to start? As a second plan...


With my respects.

Bye.

--
Server ACİM
- Besteci (Composer)
- İnönü Üniversitesi Öğretim Üyesi (Full Professor of Music Composition 
at Inonu Universitesi - Malatya - TURKEY)

- Linux Mint Kullanıcısı ve Destekçisi (Linux Mint User and Supporter)

http://google.com/+AcimNameTr
http://about.me/server.acim

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Tuplets spaced unevenly

[Javier Ruiz-Alma]

Yes.  Perfectly cured now.
Javier

-Original Message-
From: Simon Albrecht [mailto:simon.albre...@mail.de] 
Sent: Friday, November 13, 2015 1:59 AM
To: Urs Liska ; lilypond-user@gnu.org
Subject: Re: Tuplets spaced unevenly

On 13.11.2015 09:40, Urs Liska wrote:
>
> Am 13.11.2015 um 09:11 schrieb Noeck:
>> Hi Javier,
>>
>> this has been solved in some 2.19 version. In 2.19.21 the tuplets are 
>> evenly spaced. Can you upgrade?
> In case you *have* to use 2.18 there's a workaround by restarting a 
> spacing section. I don't have the command available but you can first 
> try looking that up in the manual.

\newSpacingSection

HTH, Simon




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Combined marks (rehearsal mark, fermata) + break

[Thomas Morley]

2015-11-13 6:47 GMT+01:00 Jay Anderson :
> I know I can do this to combine marks:
>
>   \mark \markup { \override #'(baseline-skip . 3) \center-column {
> \line { \box \bold "P" }
> \line { \musicglyph #"scripts.ufermata" }
>   } }
>
> This produces a rehearsal mark over a fermata over a bar line. However
> when this occurs at a line break I want the fermata over the barline
> before the break and the rehearsal mark at the beginning of the line
> after the break. Is there a good way to do this currently? (the
> lilypond web site appears unreachable again so I haven't done my
> usually scouring there.)

You could do something at the lines of:

\version "2.19.29"

#(define (combine-marks mrkup)
  (lambda (grob)
(let* ((default-stencil (ly:grob-property grob 'stencil))
   (mrkp-stencil (grob-interpret-markup grob mrkup))
   (break-dir (ly:item-break-dir grob)))

  (ly:grob-set-property! grob 'stencil
   (case break-dir
((0)
 (ly:stencil-combine-at-edge
   (ly:stencil-aligned-to mrkp-stencil X CENTER)
   Y
   UP
   (ly:stencil-aligned-to default-stencil X CENTER)
   1 ;; padding
   ))
((1)
 default-stencil)
((-1)
 mrkp-stencil))

rM =
#(define-music-function (mark mrkp)(ly:music? markup?)
  #{
\once \override Score.RehearsalMark #'break-visibility = #'#(#t #t #t)
\once \override Score.RehearsalMark #'before-line-breaking =
  #(combine-marks mrkp)
$mark
  #})

\relative {
  c'1
  \mark \default
  d
  %\break
  \rM
  \mark \default \markup { \musicglyph #"scripts.ufermata" }
  e
  \mark \default
  f
}

Which will cause different behaviour at line-start/middle/end.
Neil's engraver can't do this, iirc.
Though, with this approach fermatas above _and_ below are not easily settable...

>
> If there's not a good way to do this today, one feature that I think
> would solve this cleanly is adding a fermata barline type. So the
> above would be:
>
> \bar "(|"
> \mark \markup { \box \bold "P" }
>
> Where '(' in the bar means a fermata above the bar. We could include
> "(|", "|)", and "(|)" for fermatas above, below, and above and below
> (and of course variations with different actual bar types). What do
> you think? Is it too strange to put this as part of the bar line?


Adding fermata to a bar-line will display the fermata at the barlines
of every Staff of a StaffGroup.
Not what we would want.

Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Urs Liska]

Am 13.11.2015 um 18:51 schrieb Simon Albrecht:
> On 13.11.2015 17:19, Federico Bruni wrote:
>> Il giorno ven 13 nov 2015 alle 11:58, Urs Liska 
>> ha scritto:
>>> I suggest (and if noone objects will do it)
>>> renaming the "openlilylib" repository to "snippets"
>>> -> https://github.com/openlilylib/snippets
>>> NOTE: This may require users to adapt their repository set-ups and
>>> LilyPond include path settings
>>> creating a new repository
>>> https://github.com/openlilylib/oll-core
>>> where the stuff from /ly/_internal will be moved (reviewing a number
>>> of things along the way)
>>>
>>> Regaring the location of the individual libraries, what would you
>>> consider best:
>>> adding all beside oll-core
>>> (keeping the option that anyone creates libraries in their own place)
>>> creating a new openlilylib sibling organization for that purpose
>>> Just have library maintainers maintain their repos in their own
>>> namespace
>>> (providing a central listing of available libraries in some place,
>>> of course)
>>
>> I would avoid confusion and keep a single organization.
>>
>> The first option is the best IMO. I don't see the benefit of keeping
>> the libraries in separate places. Libraries are the core content of
>> openlilylib, not an additional feature (like e.g. an editor plugin).
>
> The idea behind the new setup would be that the only ‘core’ content of
> openlilylib is some basic infrastructure, such as is contained in
> /ly/_internal. Every library can be used independently and
> arbitrarily, so they don’t make up any ‘core’.
>
>> It's all plain text files, the size of the repository won't be big.
>
> Well, the memory size has never been the point, I think. It’s rather
> the difficulty of maintaining and managing a potentially great number
> of libraries, if e.g. everybody with push access to any of the
> libraries can push to all the other libraries too.

My main concern is that we'd end up with a large number of "library"
repositories and a few "other" ones mixed up. But Federico's comment
made me realize that we actually should see it from the other side: The
github/openlilylib organization should *only* contain the libraries (one
"core" and numerous libraries) while we should create an additional
organization for everything else. From the current state the oll-latex
and the lily-fonts repos should be moved to that new organization, and
when we create other "programming" or other non-library repositories
(e.g. a tool for building docs from LilyPond files) they should go there
too.

Urs


>
> Yours, Simon


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Tempo equivalence markup

[Pierre Perol-Schneider]

Hi Andrew,

I'm not sure to understand what you're looking for.
A more precise description or a teeny example would have been helpful.
Anyway, here's something I've done i order to look-like your picture:

\version "2.19.31"

my-tempo = \markup {
  %% Left arrow:
  \overlay {
\arrow-head #X #LEFT ##f
\override #'(thickness . 1.5)
\draw-line #'(8 . 0)
  }
  \hspace #0.5
  \lower #0.5

  %% Note value 1:
  \overlay {
\raise #3.5 \beam #0.7 #-.5 #.4
\raise #2.8 \beam #1.0 #-.5 #.4
\override #'(thickness . 1.5)
\draw-line #'(0 . 3.5)
\rotate #10
\translate #'(-0.05 . 0.1)
\musicglyph #"noteheads.s2"
  }
  \lower #1 "="
  \hspace #0.5
  \lower #0.5

  %% Note value 2:
  \overlay {
\raise #3.5 \beam #0.7 #-.5 #.4
\raise #2.8 \beam #1.0 #-.5 #.4
\raise #2.1 \beam #1.3 #-.5 #.4
\override #'(thickness . 1.5)
\draw-line #'(0 . 3.5)
\rotate #10
\translate #'(-0.05 . 0.1)
\musicglyph #"noteheads.s2"
  }
  \hspace #0.5

  %% Right arrow:
  \overlay {
\arrow-head #X #RIGHT ##f
\override #'(thickness . 1.5)
\draw-line #'(-8 . 0)
  }
}

\relative {
  \tweak extra-offset #'(4 . 0)
  \tempo \my-tempo
  \tuplet 5/4 8 { g'32 g g g g g g g g g } s
}

HTH,
Pierre

2015-11-13 6:34 GMT+01:00 Andrew Bernard :

> The attached image shows a tempo equivalence markup I need to set,
> indicating that a 32 in the context of the preceding 5/4 tuplets now equals
> a 16. The partial tuplet bracket seems complicated to do, and I don’t
> really know how to set this fragment of combined partial music and text.
> The matter is complicated by the fact that I use a custom music font, and
> worse still (!) with notehead glyphs that are specially customised also to
> achieve the very precise appearance the composer requires. So just using
> \note and so on is not what I need. Would this be best done as a type of
> ossia?
>
> Any help appreciated.
>
>
> Andrew
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Urs Liska]

Am 13.11.2015 um 15:03 schrieb Paul Morris:
>> On Nov 13, 2015, at 5:58 AM, Urs Liska > > wrote:
>>
>> Regaring the location of the individual libraries, what would you
>> consider best:
>>
>>   * adding all beside oll-core
>> (keeping the option that anyone creates libraries in their own place)
>>   * creating a new openlilylib sibling organization for that purpose
>>   * Just have library maintainers maintain their repos in their own
>> namespace
>> (providing a central listing of available libraries in some
>> place, of course)
>>
> Does this depend somewhat on how the documentation will work? 

No :-)

> Seems like centralized documentation would be easier with centralized
> repos, but maybe it would work fine either way…

We'll have a central place where libraries are registered (this is part
of the plans for the "package manager"). Registered libraries are
basically pointers to remote repositories.

That means if you create a library against openLilyLib this is
originally private (note: this will make it possible to create
private/project/house repositories that take advantage of the
openLilyLib infrastructure).
When that library is registered with openLilyLib we'll have the URL
available to pull the repository in and create the documentation.
I hope we'll also manage to provide a hook so when that library is later
pushed to Github the documentation is automatically updated.

I think we'll then provide a script to (locally) generate documentation
for just the library and another one to create and deploy the full set
of docs.

Urs

>
> -Paul

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Graham King]

On Thu, 2015-11-12 at 12:45 +0100, Urs Liska wrote:

> 
> Am 12.11.2015 um 09:09 schrieb Urs Liska:
> > Having had a night over it I realized that there is an obvious first
> > step towards b) and c) and that the infrastructure is already there for it!
> > I will add support for writing out the raw Scheme object and simply
> > integrate it as an additional export-target. I wouldn't mind if someone
> > would give me a hint with regard to (de-)serializing a Scheme object to
> > and from a file before I'll have the opportunity to look into it myself ;-)
> >
> > When that file is available I can then see at what point it's there so I
> > can see if b) or c) or both are possible.
> >
> > Urs
> >
> 
> Just for reference: I've added an issue and started work with an initial
> commit:
> https://github.com/openlilylib/openlilylib/issues/138
> 

Owing to  a technical problem (a glitch in the keyboard-seat
interface at this end) I've only just seen the last three postings in
this branch of the thread.  This looks very promising.  I might struggle
a bit at first to get from Scheme to lilypond markup, but that's nothing
compared to the heavy-lifting already done.

-- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Urs Liska]

Am 13. November 2015 14:55:43 MEZ, schrieb Paul Morris :
>> On Nov 13, 2015, at 5:58 AM, Urs Liska  wrote:
>> renaming the "openlilylib" repository to "snippets"
>> -> https://github.com/openlilylib/snippets
>
>> NOTE: This may require users to adapt their repository set-ups and
>LilyPond include path settings
>What about this instead: clone or copy to a new /openlilylib/snippets
>repo, leaving the current /openlilylib/openlilylib in place for now. 
>Then users can change to the new one while the old one still works. 
>After a transition period, delete the old one.  That would provide a
>smoother transition for users.  

Sounds good. I'll do that later and try to make things clear in the READMEs.

Urs

>
>Just a suggestion.  The rest of the plan seems fine to me.
>
>-Paul

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Paul Morris]

> On Nov 13, 2015, at 5:58 AM, Urs Liska  wrote:
> Regaring the location of the individual libraries, what would you consider 
> best:
> 
> adding all beside oll-core
> (keeping the option that anyone creates libraries in their own place)
> creating a new openlilylib sibling organization for that purpose
> Just have library maintainers maintain their repos in their own namespace
> (providing a central listing of available libraries in some place, of course)
Does this depend somewhat on how the documentation will work?  Seems like 
centralized documentation would be easier with centralized repos, but maybe it 
would work fine either way…

-Paul___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Thu, 2015-11-12 at 10:38 -0600, David Wright wrote:

> On Tue 10 Nov 2015 at 13:52:33 (+), Graham King wrote:
> > On Mon, 2015-11-09 at 21:53 -0600, David Wright wrote:
> > On Mon 09 Nov 2015 at 23:22:14 (+), Graham King wrote:
> > > On Mon, 2015-11-09 at 14:55 -0600, Christopher R. Maden wrote:
> > > On 11/09/2015 02:47 PM, Kieren MacMillan wrote:
> > > > The very first thing they said to me was, “Add measure numbers.”
> > > > That’s sufficient reason for me.  =)
> > > Good answer.
> > > In that case, I would pick one part, and force those measure 
> > numbers in
> > > as numeric rehearsal marks in the other parts.
> > > Otherwise, you’d need a translation guide...
> > > ~Chris
> > > I guess Gould has a point.  I've just realised that, under my system 
> > as I
> > > described it, a part could have the same bar number twice.  For 
> > example, in the
> > > attachment below, T has two bars "9".  But apart from an ill-chosen 
> > number (in
> > > this case), one could regard the "bar numbers" as "numeric rehearsal 
> > marks".
> > > Different mechanism, different formatting, same result.  In practice, 
> > for the
> > > sort of music I'm dealing with, the polymetric sections tend to be 
> > quite short
> > > so, for the most part, bar numbers are more helpful than rehearsal 
> > marks.
> > 
> > This is avoidable if each new bar is numbered with 1+(number of the
> > bar—looking across all the parts—that most recently finished). Not
> > something I could automate with my zero knowledge of scheme.
> > 
> > Very logical.
> > Advantages:
> > +1Might be amenable to automation.
> > +2Robust with respect to re-formatting.
> > +3Supports any variation of Staff.BarNumber.break-visibility (I think).
> > 
> > Disadvantages:
> > -1On a given line, bar numbers increase in strange and surprising ways,
> > giving potential for confusion.
> 
> That's unavoidable by any scheme. Where a player has a part that has
> many bars in one line (eg a slow-moving bass part where some other
> parts have many more notes), the player will see multiple jumps in
> their line, each where your "reference part" starts a new line in
> its score. These jumps could be forwards or backwards.

I see your point.  I'm dealing with a special case however, in which
there is just a vocal score (no separate parts).  Clearly, your scheme
is superior in the general case.

> 
> >  One cannot just count from the start of the
> > line and announce a bar number.
> 
> Oh, I don't think you can get away without labelling every bar in
> every part. We're just discussing what those labels will say.
> 
> > For that reason alone, I'm inclined to favour:
> > oCounting the bars of the top visible staff of the system, whilst
> > oAllowing discontinuity at the start of each line to accommodate other
> > parts that might have more bars in the previous line.
> 
> The "start of each line" will be different in each and every score:
> the full score, the vocal score, the choral score, and all the parts.
> *Their* discontinuities will be all over the place, with jumps
> backwards and forwards! Exciting stuff.
> 
> So I see further advantages than just those in your list:
> 
> +4 Bar numbers monotonically increase throughout every part.
> +5 Bar numbers are a defined and intrinsic property of the music,
>not an accident of one particular layout. In other words, the
>bar number of every bar is known *before* LP tries to calculate
>linebreaks and pagebreaks.
> 
> > But that's just a personal preference.  I wouldn't want to impose it on 
> > anyone
> > else!  (and I'm prepared to accept the need to fiddle with bar numbers 
> > manually
> > at a late stage in the editing process).
> 
> So what you're saying is (correct me if I'm wrong) you typeset the
> music *in it's final form*, then sit down with the printout and
> annotate the "reference part" bar numbers, then re-edit the source
> putting in all the \set Score.currentBarNumber commands for each and
> every line of the reference part.

not necessarily every line.  Different assumptions about the musical
material - see below.

> 
> Now comes the interesting bit: figuring out the bar numbers for all
> the other parts and forcing them to match the reference part.
> 
> And if a late correction has the effect of shifting a bar from one
> line to another in the reference part, you're scuppered.


Yes, all (mostly) correct, believe it or not!  For my purposes, that's
not a lot of work, since (i) the polymetric sections tend to be quite
short, (ii) the piece is never published other than in score form and,
(iii) re-working for corrections is rare (and if needed, a new set of
printouts can be run off).  I fully accept that this is a special case
of a much more difficult general problem to which your analysis applies.
I'm not trying to impose this 

Re: Scholarly footnotes

[Simon Albrecht]

On 13.11.2015 13:29, Graham King wrote:

I might struggle a bit at first to get from Scheme to lilypond markup


In case you don’t know about that already: 
 
might help.


Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Urs Liska]

Am 13. November 2015 13:29:30 MEZ, schrieb Graham King 
:
>On Thu, 2015-11-12 at 12:45 +0100, Urs Liska wrote:
>
>> 
>> Am 12.11.2015 um 09:09 schrieb Urs Liska:
>> > Having had a night over it I realized that there is an obvious
>first
>> > step towards b) and c) and that the infrastructure is already there
>for it!
>> > I will add support for writing out the raw Scheme object and simply
>> > integrate it as an additional export-target. I wouldn't mind if
>someone
>> > would give me a hint with regard to (de-)serializing a Scheme
>object to
>> > and from a file before I'll have the opportunity to look into it
>myself ;-)
>> >
>> > When that file is available I can then see at what point it's there
>so I
>> > can see if b) or c) or both are possible.
>> >
>> > Urs
>> >
>> 
>> Just for reference: I've added an issue and started work with an
>initial
>> commit:
>> https://github.com/openlilylib/openlilylib/issues/138
>> 
>
>Owing to  a technical problem (a glitch in the keyboard-seat
>interface at this end) I've only just seen the last three postings in
>this branch of the thread.  This looks very promising.  I might
>struggle
>a bit at first to get from Scheme to lilypond markup, but that's
>nothing
>compared to the heavy-lifting already done.

The problem is that so far the export isn't proper Scheme but a string 
representation that LilyPond won't even read in.

>
>-- Graham
>
>
>
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: RFC: new location for openLilyLib repository

[Paul Morris]

> On Nov 13, 2015, at 5:58 AM, Urs Liska  wrote:
> renaming the "openlilylib" repository to "snippets"
> -> https://github.com/openlilylib/snippets 
> 
> NOTE: This may require users to adapt their repository set-ups and LilyPond 
> include path settings
What about this instead: clone or copy to a new /openlilylib/snippets repo, 
leaving the current /openlilylib/openlilylib in place for now.  Then users can 
change to the new one while the old one still works.  After a transition 
period, delete the old one.  That would provide a smoother transition for 
users.  

Just a suggestion.  The rest of the plan seems fine to me.

-Paul___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user