Frescobaldi release - asking for support

[Urs Liska]

Hi all,

after ages we hope to see a new Frescobaldi release 3.1 in the not-too-distant 
future. While I can't say “tons of new features” it will be an exciting update 
with notable visible features and invisible improvements. Among the most 
important things that have been implemented since the last release (available 
when running Frescobaldi from its Git repository) are:

* An Extensions API
  (allowing easily adding functionality to Frescobaldi)
* A Document Fonts dialog
* Bugfixes and editor improvements
* Improvements in the handling of MusicXML imports
  (Note: this doesn't update the actual conversion, only the handling in 
Frescobaldi)
* Sessions can be grouped
* Proper handling of paper orientation in the Score Wizard

Among the features we hope will make it into the next release are:

* Rewriting of the Music View code, which will mainly improve future development
  but has some implications that can already be seen now.
  * More image formats (for the Music View and the Manuscript viewer)
  * Better handling of "pages"
  * Integration of PDF and SVG viewer in *one* tool
  * pages can be overlaid, which will make visual diff tools possible
* A Multi-process Job Queue
  This has already been implemented but needs further testing and
  an interface to be of more use.
  Frescobaldi can be assigned a number of "runners" (e.g. six if you have an 
eight core CPU)
  which dynamically assign (compilation) jobs. In a project I have thrown 
thousands of jobs
  (compilation of a huge number of score snippets) at it, and this ensures that 
all six
  (or whatever) cores are always busy without overloading the PC (if you simply 
start those
  1000 external processes the OS will do the job but flood the *whole* CPU).
* A unified compilation manager
  I've successfully used the Job Queue in an extension but it is not too well
  integrated with Frescobaldi's general operation.
  A new tool is planned to integrate the various compilation modes (Preview, 
Publish,
  Custom, Layout Control) and to integrate with the job queue.
  The job queue will also be used to balance the load with engraving processes 
and
  Frescobaldi's own work
* Removing the slowdown with large LilyPond files
  Large files can make working with Frescobaldi unusably slow
  (because updating the information for syntax highlighting and code completion
  can take a long time).
  This can be completely removed by moving this parsing to an external process 
using the
  Job Queue.
* Integrate basic Git support in the editor
  There has been much work as part of a GSoC project that *still* hasn't been 
merged.
  Probably it needs more review but it would be really good to finally get this 
done.

BUT:
This comes with a big caveat: as with LilyPond itself we're suffering from 
serious shortage of developer manpower, and so in order to make this happen I 
strongly (if not to say desperately) urge you to consider helping us, at least 
for the next months. This is an opportunity not only for developers to join the 
effort of bringing Frescobaldi (which I know most of you love and use) to the 
next level. You can help with

* Testing and discussing
  (requirement: Running Frescobaldi from Git, Github account)
* Translating
* Writing documentation
* Implementing
  (we have a number of issues tagged as "beginners"
  
https://github.com/frescobaldi/frescobaldi/issues?q=is%3Aopen+is%3Aissue+label%3Abeginner
 )
* Coding, especially reviewing Python code
* Making installers work on Mac and Windows

Best
Urs

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

Lilypond on OS X Catalina

[Allan Kinnaird via lilypond-user]

Apologies if this is an inappropriate forum to raise this question, but I am a 
Lilypond user wanting to to continue using Lilypond.
Apple flagged on the release of Mojave that it would be the last version of OS 
X to support 32-bit applications, and the indications are that Catalina will 
only operate with 64-bit applications.
On a system analysis, Lilypond is the only significant application I have still 
showing as 32-bit.
Is anyone working on a Catalina compilation of Lilypond? If so, when might the 
package be posted?
I am willing to try compiling from source, in spite of recommendations against 
on the website.
I know there may be problems - the website provides suggestions for compiling 
using dependencies from MacPorts, while experience has guided me away from 
MacPorts. I use Homebrew as my main package manager, and it does not play well 
with MacPorts.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond on OS X Catalina

[Henning Hraban Ramm]

> Am 2019-09-13 um 19:15 schrieb Allan Kinnaird via lilypond-user 
> :
> 
> Apologies if this is an inappropriate forum to raise this question, but I am 
> a Lilypond user wanting to to continue using Lilypond.
> Apple flagged on the release of Mojave that it would be the last version of 
> OS X to support 32-bit applications, and the indications are that Catalina 
> will only operate with 64-bit applications.
> On a system analysis, Lilypond is the only significant application I have 
> still showing as 32-bit.
> Is anyone working on a Catalina compilation of Lilypond? If so, when might 
> the package be posted?
> I am willing to try compiling from source, in spite of recommendations 
> against on the website.
> I know there may be problems - the website provides suggestions for compiling 
> using dependencies from MacPorts, while experience has guided me away from 
> MacPorts. I use Homebrew as my main package manager, and it does not play 
> well with MacPorts.

In my experience (on OSX 10.9.5 and Mojave), you can’t install Lilypond and 
Frescobaldi with HomeBrew, but quite easily with MacPorts (lilypond-devel and 
frescobaldi-devel).
For other applications HomeBrew might be better.
In principle these systems shouldn’t interfere with each other… (Worked for me 
while I didn’t try to compile other software against libraries installed with 
one of those.)

Greetlings, Hraban
---
fiëé visuëlle
Henning Hraban Ramm
https://www.fiee.net





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

Re: Lilypond on OS X Catalina

[Hans Åberg]

> On 13 Sep 2019, at 19:30, Henning Hraban Ramm  wrote:
> 
>> Am 2019-09-13 um 19:15 schrieb Allan Kinnaird via lilypond-user 
>> :
>> 
>> Apple flagged on the release of Mojave that it would be the last version of 
>> OS X to support 32-bit applications, and the indications are that Catalina 
>> will only operate with 64-bit applications.
>> On a system analysis, Lilypond is the only significant application I have 
>> still showing as 32-bit.
>> Is anyone working on a Catalina compilation of Lilypond? If so, when might 
>> the package be posted?
>> I am willing to try compiling from source, in spite of recommendations 
>> against on the website.
>> I know there may be problems - the website provides suggestions for 
>> compiling using dependencies from MacPorts, …
> 
> In my experience (on OSX 10.9.5 and Mojave) … install Lilypond and 
> Frescobaldi … quite easily with MacPorts (lilypond-devel and 
> frescobaldi-devel).

At least the first one is supported (actively maintained), and one installs (as 
root) with
  port install lilypond-devel
with no other hands-on installation other than making the program visible, 
which can be done with a script called say ‘lilypond’ in a suitable location 
with:
export LC_CTYPE=en_US.UTF-8
export LANG=en_US.UTF-8
exec /opt/local/bin/lilypond "$@"

I added the LC_CTYPE and LANG environment variables, because on MacOS they are 
set without a prefix ‘en_US.’ which may confuse some software.

The MacPorts installation only calls stuff inside /opt/ so it does not 
interfere with anything outside. If one is also using stuff in /usr/local/, 
then one will have to set the PATH appropriately. I have set /usr/local/ before 
/opt/local/.

As for MacOS 10.15, it may take some time to get MacPorts updated, in the past 
it has been some month or so after the new OS arrival.



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

Re: Allowing TextSpanner lines to collide, but not the end text

[michaellee94]

I'm going to bump this, if that's alright. Is there a way to disable
collision avoidance for just the line of a TextSpanner, not the ends? Maybe
ditch the TextSpanner idea altogether? Is there a clever use of
staff-padding?



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

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

Producing scores for visually impaired and blind people

[Jacques Menu]

Hello folks,

I’ve thought of a possibility which surely others have already considered, and 
I’m not sure whether the idea makes sense at all.

This would consist in printing LilyPond scores in 3D on thin plates, analog to 
was was done at the time when engravers built scores with pieces of metal. 

Maybe with a large enough scaling factor, such ‘printbossing’ would be readable 
by trained braille readers with their fingers, benefitting from the non-linear 
nature of graphical scores and the high quality of Lily’s scores. Such plates 
could also be piled up without the risk of damaging the contents, which may 
occur with embossed paper.

What do you think? Please excuse me if my question is silly...

JM


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

Re: Producing scores for visually impaired and blind people

[Hwaen Ch'uqi]

Greetings Jacques,

In truth, I hardly think the idea is silly. In fact, if my limited
historical knowledge of Braille generally is correct, something like
this was done before Napoleon's martial code was adapted by Louis
Braille. The drawback at that time was the sheer volume of a text and
thus its portability. But I wonder if, now 200 years later, some of
that bulk could be streamlined.

Hwaen Ch'uqi


On 9/13/19, Jacques Menu  wrote:
> Hello folks,
>
> I’ve thought of a possibility which surely others have already considered,
> and I’m not sure whether the idea makes sense at all.
>
> This would consist in printing LilyPond scores in 3D on thin plates, analog
> to was was done at the time when engravers built scores with pieces of
> metal.
>
> Maybe with a large enough scaling factor, such ‘printbossing’ would be
> readable by trained braille readers with their fingers, benefitting from the
> non-linear nature of graphical scores and the high quality of Lily’s scores.
> Such plates could also be piled up without the risk of damaging the
> contents, which may occur with embossed paper.
>
> What do you think? Please excuse me if my question is silly...
>
> JM
>
>
> ___
> 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: Producing scores for visually impaired and blind people

[Karlin High]

On 9/13/2019 2:52 PM, Hwaen Ch'uqi wrote:

But I wonder if, now 200 years later, some of
that bulk could be streamlined.


Here is a thread from November 2017, with a new user introduction from 
Daniel Chavez. A blind musician using LilyPond to make sheet music for 
sighted people.




That's where I learned that Music Braille exists:


How that would compare in practice to LilyPond's standard output printed 
in 3D is probably a question for someone who knows the experience of 
blind musicians.

--
Karlin High
Missouri, USA

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

Re: Producing scores for visually impaired and blind people

[Hwaen Ch'uqi]

Greetings Karlin,

Braille music does indeed exist, though significant variation in its
structure and even syntax persists despite attempts at
standardization. The main difference between Braille music and printed
music is that the former is not in any wise spatial. One benefit of
this is that stem directions need never be an issue, and, therefore,
voices in - for example, a piano or organ score - can be accumulated
with ease and clarity, so long as the hands can play them. But there
are certainly benefits to enjoying the spatial dimentions, especially
where a full score for an ensemble would be concerned.

Hwaen Ch'uqi


On 9/13/19, Karlin High  wrote:
> On 9/13/2019 2:52 PM, Hwaen Ch'uqi wrote:
>> But I wonder if, now 200 years later, some of
>> that bulk could be streamlined.
>
> Here is a thread from November 2017, with a new user introduction from
> Daniel Chavez. A blind musician using LilyPond to make sheet music for
> sighted people.
>
> 
>
> That's where I learned that Music Braille exists:
> 
>
> How that would compare in practice to LilyPond's standard output printed
> in 3D is probably a question for someone who knows the experience of
> blind musicians.
> --
> Karlin High
> Missouri, USA
>

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

Re: Producing scores for visually impaired and blind people

[Dirk Koopman]

There is something called "Music Braille", invented by the man himself. 
But, I am reliably informed by an ex-chairman of the RNIB (a fine tenor) 
that it really is too much trouble to use because it is a) verbose b) 
requires a spare hand that would otherwise be playing the instrument and 
c) is made even more difficult when lyrics are involved.


So he learns his part, by ear, and just uses normal  braille for the 
underlay.


Dirk

On 13/09/2019 20:33, Jacques Menu wrote:

Hello folks,

I’ve thought of a possibility which surely others have already considered, and 
I’m not sure whether the idea makes sense at all.

This would consist in printing LilyPond scores in 3D on thin plates, analog to 
was was done at the time when engravers built scores with pieces of metal.

Maybe with a large enough scaling factor, such ‘printbossing’ would be readable 
by trained braille readers with their fingers, benefitting from the non-linear 
nature of graphical scores and the high quality of Lily’s scores. Such plates 
could also be piled up without the risk of damaging the contents, which may 
occur with embossed paper.

What do you think? Please excuse me if my question is silly...

JM


___
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