On Tue, Jan 14, 2020 at 10:10 PM kieren_macmillan kieren_macmillan < kieren_macmil...@sympatico.ca> wrote:
> Hi Paolo (et al.), > > > Why do I need to move a grob? > > For the simple fact that any score, in order to have a * professional * > > appearance, needs HUNDREDS of these adjustments. > > Even the simplest ones. > > I think we all agree on that. > > Now… At one end of a philosophical spectrum lies the point where everyone > spends > all their energy, time, and brainpower trying to make Liypond do all of > those > adjustments automagically; at the other end lies the point where we say > "It’s > good enough now; let’s build a tool by which the user can make the > necessary > adjustments."; and somewhere in between is the spot where energy, time, and > brainpower goes into both those efforts. That last spot is different for > each of > us — some want to spend more time improving Lilypond’s decision-making > capabilities, some want to spend more time giving users tools to fix what > LIlypond doesn’t do perfectly. > > Hello Kieren There's a misunderstood of that, I think. I did not make my editor for fixing what Lilypond doesn't do perfectly. Really not. I made the editor for doing: 1) placements that CANNOT be done automagically in *any case*. I can assure (and totally convinced) that even with a *perfect* Lilypond, too many things still have to be adjusted manually. Even with the most sophisticated A.I (artificial intelligence) or a neural network you cannot adjust many things automagically. It's simply impossible. It's like you say: "I want a tool that automagically write a romance". Impossible. You have to deal with too many things, and you must have an *aesthetic* perspective of things that a calculator won't have nor now nor in the next 500 years (at least) 2) my editor doesn't fix anything that Lilypond doesn't do perfectly. It only maps the same properties that you are forced to hand-write by using a *RULER* (with staff-space units). And it reports them on the text score. Exactly as you do by hand-writing. Please understand that this is absolutely not a WYSIWYG editor. Instead, it's an *assistant* for text-writing. It assists the user in avoiding the trial-and-error-process. This is common feature for many *text* editors, not for WYSIWYG ones. That's all. Sorry if I have to insist on that, but there seems to be a general big misunderstood of what I'm doing. I don't like WYSIWYG editors for music. And I don't want to use them. I think they end in slowing down the editing process. That's only my opinion (some other experienced people do prefer WYSIWYG stuff). And that's why I would not use Finale even if it becomes GPL/Linux fully supported. Anyway, as said before, I'm not trying to convince anyone about what I think. Simply: I don't have time to join endless discussions. Then, I do what I need for my scores, and share it, hoping it can be useful for other people too (so to receive support as feedback, which speeds up the development of the editor project). This is how FSF works. That said, I really thank you for your support so far and hope we can find a solution for the starting offset problem. Best, Paolo > >
