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

[Urs Liska]

Am 23.04.2015 um 16:13 schrieb 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)

Well, LilyPond is a compiler as you said. A C++ compiler doesn't have a 
GUI for simplified object management. LilyPond suggests to have 
dedicated IDEs for that. I assume Denemo has what you are asking for 
here (simplified graphical representation while entering).

>    -- menues for all 'out of the box' modificators (articulation, overrides,
>   tweaks, ...)

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.

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

Seems like there could be good ideas in that.

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

We have started implementing something like this in Frescobaldi's SVG 
viewer (but had to stop because we have to wait for some underlying 
library to be more finished. What we had achieved is to be able to drag 
text items around and calculate the corresponding 'extra-offset from it 
and displaying it in an "object inspector" stub. Once we have the 
library available to properly update the source file we will add other 
features:
- dragging of pitches
- shaping of curves
- reattaching items to other notes
- etc.

Of course this should play well together with the mentioned object 
editor, so you can "see" the values you are producing by dragging. And 
(hopefully) it should offer different approaches to insert the tweak in 
the source file - I think 'extra-offset should always be the last resort 
only.

> 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

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