Re: [Frescobaldi] State of Frescobaldi development

[Wilbert Berendsen]

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!

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.

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 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.

- 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.

  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.


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/