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/