Re: New Sibelius to LilyPond conversion suite

[Kirill]

Bertalan Fodor (LilyPondTool <lilypondtool <at> organum.hu> writes:

> 
> But why don't you dump directly to lilypond? Because Sibelius plugin 
> interface is not so good as writing in Ruby?
> 
> Bert
> 

That was my first naive attempt, to do all the work in a Sibelius plugin.
(That would have made things 100% portable, I thought)

However, it turned out later, translation from Sibelius to LilyPond is more
of an art than engineering, since there is no one-to-one correspondence
between the teo representations of music.
A very intelligent translator, not a mere converter, is required to get
decent results.
Initially (some may remember my earlier posts from 2006) I have tried to
implement all the translation intelligence in a Sibelius plugin (it was
fairly functional, and I still have it lying around but have long abandoned it).
When it grew to certain size it became simply impossible to maintain. There are
no development tools available in Sibelius, not for debugging,
not for anything.
Plus, it was ultra-slow for large score (Sibelius ManuScript has a very
slow interpreter).

Hence I decided to outsource all the logic to an external script.
At the time I was impressed by Ruby, so...

As far as users have reported, Ruby comes preinstalled on Mac OS X.
Most Linux users would have Ruby also, or can obtain it with a single
apt-get/emerge command.
For Windows users who don't want to install Ruby, I'm packaging the whole
thing into a standalone .EXE
So, I'm not too concerned about external dependencies.

Additionally, it agrees with the Unix philosophy of having small
independent tools to solve independent tasks.
As Johan mentioned,
> The niftiest feature is probably that everything you want/need to
> tweak can be done with convenient tools *after* making the dump.


At the moment, I think I will continue working in this direction (dumb plugin
for lossless export + intelligent scripts for translation).
I might consider writing a different output mechanism (but leaving the
translation logic intact) to produce MusicXML instead of immediately
producing .ly, but I am sceptical if it is needed.

Carl,
I promise I will maintain the project better, and will follow more robust
testing procedures (absolutely essential for this kind of tool).
I apologise for the temporary bugs, but the project is very-very young.
I'm sure in a few weeks it will be very useable.