denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Denemo-devel] [bug #47327] Continue previous work of keysig dialog mode


From: Richard Shann
Subject: [Denemo-devel] [bug #47327] Continue previous work of keysig dialog modes
Date: Fri, 04 Mar 2016 19:12:32 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.4.0

Follow-up Comment #5, bug #47327 (project denemo):


"what language does what and how they communicate"
The C code is the original code, it was started in 1999 with a very limited
intention. It is very difficult to modify without having unintended
consequences (the test suite is little more than an idea, mostly tests remain
unwritten). Well, it is also very difficult to modify because of the
accumulation of time has made it obscure. It is needed for speed in some
circumstances, although raw machine speed has increased dramatically since it
was written.

The Scheme language is used for everything else - the vast majority of the
menu items and all the palettes are just scheme scripts (you can browse the
menu hierarchy below actions/menus to see these). Occasionally new
C-primitives are written to support things that remain inaccessible to the
Scheme code.

"... the same net result", Well the Dialog lets you dictate that the LilyPond
syntax generated is \key c \minor rather than \key ees \major, while the
red/blue sensitive areas don't let you control this.

One thing to understand is that Denemo stores notes not what they look like.
That is Denemo stores something called  c''-sharp and that will be displayed
with or without a sharp sign in front of it depending on some display
algorithm written in 1999. What it looks like is irrelevant to the final
typeset score where it will be displayed according to the LilyPond rules set.
(The LilyPond default means there is a discrepancy in some circumstances -
there is a bug report for that).

Inserting/changing key signatures makes no difference to the notes that are
present, but they may be displayed differently.

"... and the dialog seem to have the same result"
Try inserting a key signature change from Major to Minor you will see that you
have to re-set the key name as it changes on you...

For your scenario you would just have a script that stepped on from the
current position (where a key signature change has just been inserted)
changing the notes. It would be a loop that stopped when the end of the staff
was reached (d-NextChord) is #f or some such. The body of the loop would get
the notes and change them (it would also have to step through the notes of any
multi-note chord by looping).





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47327>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]