Hi Wilbert,

On Tuesday, January 17, 2017 at 10:08:42 AM UTC+1, Wilbert wrote:
>
> Dear Friends, 
>
> I apologize for being so silent in the Frescobaldi world the past 
> months, and not taking the time to respond to some private e-mails, 
> which I surely did read and highly appreciated! 
>

Thank you for getting back to us. I hope you don't feel intimidated by me 
going public the way I did. I just didn't see another way - and for the 
time being it looks like it fulfilled its goal ...
 

>
> I had so many, and demanding, recitals with Christmas that I even 
> didn't get out a new release... I have been busy with my musicianship 
> (church and city organist in Doesburg, choir conductor, a growing 
> number of organ pupils), my carillon studies (which are almost finished 
> by now) and my family. There was virtually no time left for Frescobaldi 
> development. 
>
>
I have all understanding for that situation, and essentially you don't have 
any obligation to work on Frescobaldi. But of course "the world" wants you 
to do so and deeply appreciates your tool and your work. So ...
 

> However, I will gradually have more time the coming period, and want to 
> devote more time and love to Frescobaldi, in coordinating development 
> and making structural improvements.



... I'm more than happy to read this.

 

> I also feel appreciated and 
> inspired by you, co-developers, co-thinkers, bug-hunters and users. 
> Thank you for that!! 
>
> There are some things on my todo-list that are difficult to solve, and 
> they also caused some delay in my work on Frescobaldi. (I actually 
> devoted quite a lot of thinking time to Frescobaldi!). This mainly has 
> to do with improving/designing the internal musical representation of a 
> LilyPond document, and building and querying that in a background 
> thread. 
>
> Here are my personal todo items: 
>
> - release 3.0.0 and 2.20.0 asap 
>
> - replace qpopplerview with qpageview, which can display generic page 
>   items not per se originating from a PDF, but also SVG, images and 
>   whatever else. (by having a generic Page base class). 
>
>   qpageview is already quite far developed. 
>

This is great to hear. I have quite far-reaching plans for the "Manuscript 
Viewer" that will hopefully bring Frescobaldi near or up to Edirom, the 
flagship in digital music editing today. And these rely on that underlying 
feature.

Do I get you right that this would actually make it obsolete to have an 
independent SVG viewer built on different technology? That would be great 
because it would help with integrating the different tools. For example, 
some of the tools we intend to create for graphical editing can only be 
achieved with SVG (e.g. slur shaping) while others can equally be done with 
SVG and PDF (applying changes like "flip stem direction"), so having both 
in one widget might simplify this greatly.
 

>
> - decide on ly.music or ly.xml; the internal musical representation of a 
>   LilyPond source file, provided by the ly module and used for musical 
>   acces (and editing!) of a source document. 
>

It would be great if you keep us posted, even on preliminary thinking. I'm 
not exactly into this matter but would be greatly interested in the topic, 
also to spend energy on it, as it also touches the topic of format 
conversions.
 

>
>   There have been comments that using Python objects to build the 
>   ly.music tree is too expensive, and that a C xml implementation 
>   should be used to hold the document, traversed using python routines. 
>   But I'm not sure yet, I love the idea of Python objects being more 
>   simply accessible. But the objects should be simpler than the current 
>   ly.music.items objects, and have as few methods as possible, leaving 
>   advanced quiries such as the musical duration of an element to 
>   functions in the ly.music module. 
>   (https://github.com/wbsoft/python-ly/issues/3) 
>
> - as soon as a ly.music representation has been designed, implement it 
>   in a way that allows partial renewal (e.g. when a user edits the 
>   document) and that is can be created in background threads. This helps 
>   editing large LilyPond documents on less powerful machines, which 
>   currently can become cumbersome. The tokenizing (ly.lex) is fast 
>   enough, but building and traversing musical structures is too slow. 
>
>
This is pretty exciting, and I'm surprised to see how long and detailed our 
discussion in that python-ly issue was, two years ago.

There is one more fundamental and structural thing that had been on the 
table and that would be extremely valuable to approach as one of the next 
steps: implementing a plugin infrastructure for Frescobaldi. There are 
several ideas for improvements that would make Frescobaldi an even better 
tool but that may not all be appropriate to squeeze into the main product. 
I'm thinking of, say, a user interface for openLilyLib support or the 
ability to create a project management interface.

My best wishes for now
Urs
 

>
> So far, 
> Please give me some time to gradually get back into the development 
> process and iron out the most important issues and make two nice 
> releases shortly....:-) Then we'll see what's next! 
>
> Thanks again, and a happy and fruitful new year to everybody! 
> Wilbert 
>
> -- 
> Frescobaldi homepage: http://www.frescobaldi.org/ 
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to