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

[ArnoldTheresius]

Federico Bruni wrote
> ...
>> > personally I find lilypond code in \relative mode easier to read.

Perhaps, it's only a problem because the editors we use are not able
to translate automatically between relative and absolute octave notation.

Well, back to the original question, what may professional users expect from
Lilypond, I would like to view Lilypond with the eyes of a mechanical
engineer
(using CAD programs) and a programmer (using compilers and IDEs):

I'm using one of these huge (and expensive) 3D CAD programs, where you
design your 3D parts, combine them into assemblies (multiple levels), and
create drawings from resp. for the parts and assemblies.
A modification in one part (or any 3D model) will be reflected in all it's
usage
(where ever it is referenced).
Such a software is not a "one level WYSIWYG" software, you have different
representations (and different tools for modification) when working on the
3D models or when working on drawings.
Even such a CAD software is not used by every company - many still use
2D software because due to their requirments they do not need so complex
tools which need much more training.

With this background Lilypond was a software I was looking for:
- the PDF output (MIDI output too) I did compare with the CAD drawings
(may contain multiple sheet) and their drawing views.
- the lowest level for "variable" I did compare with the "3D parts", the
sequential and simultaneous music using these variables I did compare
with the "asseemblies".
- one modification (e.g. corrected pitch) in the lowest level of definition
will be reflected in all usages (single parts, additional parts for
transposing
instruments, partial scores, total score, midi output)

Lilypond is (for me) a compiler - a command line compiler without IDE
(integrated development environment) - and yes, I'm using it in the
command line.

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)
  -- menues for all 'out of the box' modificators (articulation, overrides,
 tweaks, ...)
- automatic source code update to new versions (from "open file" to
"file loaded into the RAM of the editor")
- 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)
- 'where used' handlig
  -- report of the structure
  -- with point-and-click (in the PDF) a menu e.g.: location of pitch
definition
(inside variable a) | locations of variable a reference (inside variable b)
| ...
  -- where used report while editing: this pitch definition is part of
variable a, which is used in variables b and c, ...
- quick GUI driven 'extra offset' editing, valid for just one output (PDF) 
target - without the need to guess a value, enter it (with tag) into the
source, and recompile it, and probably adjust the value again. (My
largest score now takes 25 minutes to compile and consumes
2.3 GB RAM - on Windows)

Another important topic for commercial users may be the management
of the source code for all PDFs (and other output).
And finally multiple people may have to working parallel on the same score.


ArnoldTheresius



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