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. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
