Re: What is the problem with "\relative"? (Was: Do we really offer the future?)

[ArnoldTheresius]

Hello Urs

Urs Liska wrote
> ...
>>
>> Another important topic for commercial users may be the management
>> of the source code for all PDFs (and other output).
> 
> What do you mean here?
> 
>> And finally multiple people may have to working parallel on the same
>> score.
> 
> This is something that is already working absolutely great with LilyPond 
> scores.
> 
> Urs
> 
> ...

I just think on my 'huge score'. 24 pieces (movements) originally published
with
'Piano Direction' istead of a score, I put the 17 parts (including the
'piano direction'
and 'piano solo' together to a score. Per instrument each piece a single
soucre file,
one "compilable" LY per each combination (piece and instrument, as well as
'score
of a single piece') for the 'editing workflow', and one "compilable" LY per
each
instrument part, transposed alternative instrument part and score (all 24
pieces)
for the 'publishing workflow', some common includes (e.g. Title of the
pieces) did
result in more than 900 LY files.
I can imagine, if ten persons are working parallel to make such an edition
avalible
in a short time, it's not a good idea to just save the file on a comon
shared folder,
with the danger to overwrite a file a colleague had modified and saved just
a short
time before.
Well, I admit, in CAD usage the reuse of existing objects is much more
complex.


Urs Liska wrote
>> Compared to the CAD software, Lilypond is missing (around it's kernel):
>> - a graphical user interface (GUI) to enter/edit the source (with a
>> simplified graphical representation of the music notes)
> 
> I'm not clear what you mean here, but in any case this too is an issue 
> for the IDE.
> Frescobaldi provides the Quick Insert panel. You can select multiple 
> notes in the input file or the music view and then apply e.g. staccato 
> to all notes at once.
> 
> On my way-too-long wish/todo list is an "object inspector/editor" for 
> Frescobaldi, which should basically be rather straightforward to 
> implement. This panel would be aware of the grob the cursor is currently 
> in (or the grob that has been selected in the Music View) and then show 
> all available properties that can be tweaked for that element (actually 
> Frescobaldi already knows about these properties which it uses for 
> autocompletion). Then there should be convenient ways to edit values in 
> that dialog.
> 
>> - automatic source code update to new versions (from "open file" to
>> "file loaded into the RAM of the editor")
> 
> Is this really important? I'd be scared when my editor does that 
> automatically.
> 
>> - point-and-click positions have idenpendent IDs, which are stable during
>> editing the source (e.g. if you edit the LY files and insert a line)
> 
> Frescobaldi does that.
> 
> ...

My observation on CAD usage is, approx. 3 % of the users are going to
use features which are similar to "programmng".
The remaining 97 % use the GUI only and avoid using such features,
they have to "think as a programmer".
I hope, for "music notation users" this ratio is better, but I don't believe
it'll reach 20 %.
So, a "good GUI editor for LY files" could increase the acceptance of the
users a lot.
And it's an important question for such a "GUI", how versions updates
will be handled - but this also depends on your file managment (will you
save the history in the editing process?)
What's to expect if you restart editing a 20 years old publication? Can only
the "guru" process all required updated, or is the work of the "guru"
limited
to fix the remaining problems (by using an utf8 text file editor) only?

IMHO, the publishing companies would prefer a complete suite of
lilypond (the kernel), 
an editing GUI (for user acceptance)
and file management (recommended at least for cooperation of multiple users)


ArnoldTheresius



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Do-we-really-offer-the-future-tp174675p175458.html
Sent from the User mailing list archive at Nabble.com.