bugDenemo - Bugs: bug #47327, Continue previous work of keysig...

 
 

bug #47327: Continue previous work of keysig dialog modes

Submitted by:  None
Submitted on:  Thu 03 Mar 2016 06:01:56 AM UTC  
 
Category: Feature requestSeverity: 3 - Normal
Item Group: NoneStatus: Need Info
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 04 Mar 2016 07:12:31 PM UTC, comment #5:

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

Richard Shann <rshann>
Project Administrator
Fri 04 Mar 2016 05:41:18 PM UTC, comment #4:

Thanks for continuing this discussion. This being the first time I have examined code contributed from multiple languages I apologize for mistakes in understanding what language does what and how they communicate.

I believe we are on the same page when I described: "If you change the key sig in the middle of your project – Denemo adds accidentals to preserve consistency in the written notes"

Whether you sharpen or flatten the key signature with the dialog or the red and green push controls, my observation has been the same net result: An example may make it clear:
1. I set my Key to D major
2. I proceed to fill a staff with music
3. I change the key to C major or A minor.
4. I notice that any F or C is now accompanied by a sharp accidental. Great, musically/the audio component is consistent.*(see below)
5. Untested at present - but I would presume that if you have deliberately entered an F natural, then it would show up as a plain F in your new key signature, but because of this, I would think that this may increase the complexity of an "ignore script" i.e. what you describe as the job of a "simple script that would go through the subsequent notes altering them".

Perhaps the biggest confusion I currently have is: I don't know if this script would be part of the source code or treated more like a plugin. If integrated with the program, then I would predict that it's activation could likely be tied to a simple checkbox as proposed.

*Since I am seeing a consistent result (step 4) as a result of applying step 3 (even though for me, this is only desirable in 1 of my 2 use scenarios) I am not sure what you mean by 'fix the horrible way that the current dialog switches the key when you switch from major to minor."

In my experience with key signatures the push selection and the dialog seem to have the same result (and they communicate well together). Nothing horrible about that...

Personally, I prefer to work with the dialog because it can drop a change in the middle of your piece - a very necessary feature in concert band music.

S <engbird>
Fri 04 Mar 2016 09:27:17 AM UTC, comment #3:

Well, it would be good to fix the horrible way that the current dialog switches the key when you switch from major to minor. That is a bug that has been around for a few years, largely because I introduced the possibility of clicking on the key signature to push it sharper or flatter. So people don't bother with the dialog. That method works even for those who have no knowledge of the key signature names.
If you find that you have entered the wrong notes because of not being able to decipher the key signature or the clef then a script to correct them would be the only practical way to go. (Fortunately Scheme is a very minimal language, you can learn the basic syntax in about half-an-hour, although the list format takes a lot of getting used to).
That is I'm assuming that when you say

"If you change the key sig in the middle of your project – Denemo adds accidentals to preserve consistency in the written notes"

you mean that Denemo would respond to the insertion of a key signature change by altering the notes that follow. If that is your meaning, then this would be the job of a simple script that would go through the subsequent notes altering them.

Richard Shann <rshann>
Project Administrator
Thu 03 Mar 2016 10:32:29 PM UTC, comment #2:

I don’t know anything about scheme, but perhaps if I detail a little my intentions when I optimistically thought I could contribute, it might provide a little information into what the point was because my intended contribution is probably a little more complex than something competently handled by a scripted extension.

I was thinking I would try to expand the contents of keysigdialog.c. (photoshopped proposal of a new key signature dialog attached) Specifically, I thought I would:

Expand the list of modes either
Preserving the initial design for an array of radio buttons
or change the selection to a drop down menu

Add two checkboxes (labeled here as):
Change key sig only
Equivalent major key sig help

Here’s a bit more info for the non-self-explanatory checkbox labels…

Change key sig only
If you change the key sig in the middle of your project – Denemo adds accidentals to preserve consistency in the written notes. This is a great idea if you are transcribing by ear, and then go back to tidy up your accidentals once you have deduced what the key is.
Problem: If you are transferring written notes and forgot to update (or were unable to see because of a bad copy) the key signature, you are left with a lot of corrections after the fact.

Equivalent major key sig help
For users with casual knowledge of theory, they may not be as fluent with the equivalency of key signatures so it could be nice to provide a crutch that allows them to engage the equivalent major key sig help checkbox, and with this engaged, they could select the major key from the drop down box, and the mode they want to try out (even if it`s just for the lilypond metadata and subsequent annotations). When flicking between modes, the change key sig only would be particularly important to freeze the selected notes to prevent the user from having a lot of clean up.
I think this would be possible if adding combinations to keysig.c and extra arguments to the existing “keysig_new_” functions

As you can see, these check boxes expand the point of my “feature request” quite a bit, but I figured I should start small until I better understand the intricacies of the project.

(file #36539)

S <engbird>
Thu 03 Mar 2016 09:08:00 AM UTC, comment #1:

I would like to be sure I understand what it is you would like to benefit from. You write "modes for key signature selection". This would literally imply that what you would like is that in order to get a key signature with no sharps or flats you would like to be able select from a dialog that listed "dorian" rather than C major or A minor.

More likely, you are a user that works with the LilyPond output as text, in which case having the LilyPond output text read

\key c \major

when it means

\key c \dorian

would be unpleasant.

I have long noticed that commented out declaration, with its curious typo for locrian and wondered where the code was headed at the time; instead of hard-wiring stuff like this in C, I introduced the use of Scheme as an extension language. It would be quite easy in Scheme to offer a selection of modes and output the correct LilyPond syntax and show the correct accidentals in the Denemo Display.
There is not a lot of documentation on this (some in the manual, but mostly examples in the menus, e.g. right click on Clefs->Clef Chooser and select "Get Script into Scheme Window" and then see how Drum Clef is implemented), but I can always help pointing you in the right direction.

Richard Shann <rshann>
Project Administrator
Thu 03 Mar 2016 06:01:56 AM UTC, original submission:

I was considering trying to contribute to this project by implementing one of the most important features I would benefit from: modes for key signature selection. But, when looking for the most logical place to extend key signatures in, which I figured was "keysigdialog.c", I noticed a pretty complete list of modes were listed, but commented out:
/* UNUSED
static gchar *modes[7] = { "lydian", "ionian", "mixolydian", "dorian", "aeolian", "phrygian",
"locrain"
};
*/

While I plan to continue familiarizing myself with the code I may have been underestimating the extent to which the key signature modes permeate through the rest of the code (not just local to this class) which is why this was not implemented, even though it clearly was considered. Either way, probably not a good entry level contribution.

So while I keep reading and learning about the code to find another way to contribute, I will fill this form out hoping to add my voice for this feature to perhaps encourage it's (return to) development.

Keep up the great work Denemo team!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #36539:  Denemo_KeySigModes_Proposal.jpg added by engbird (24KiB - image/jpeg - Proposed dialog selections)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by engbird (Updated the item)
  • -unavailable- added by rshann (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 29 Mar 2016 03:14:30 PM UTCrshannOpen/ClosedOpen=>Closed
    Thu 03 Mar 2016 10:32:29 PM UTCengbirdAttached File-=>Added Denemo_KeySigModes_Proposal.jpg, #36539
    Thu 03 Mar 2016 09:08:00 AM UTCrshannStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1