Decrease velocity contrast works odd

[NotationUser]

Thanks for putting it on your list but take the time you need to change it proper.

I know I have sent many posts the passed week. Some address minor bugs. Others "inconvenient miracles". I have done also many suggestions I do really not expect to happen soon.

Don't take my posts as criticism - it isn't. It is just all I can give in return for discussion and probably helping to make an already very good software even better.

[Mark W]

Hello NotationUser,

Originally Posted by NotationUser

Thanks for putting it on your list but take the time you need to change it proper.

I investigated the problem with the note velocity (loudness) contrast command not working for a single chord. I'm going to declare this as "won't fix".

It had been many years ago since I implemented this feature. There are two features for changing the note velocities for many notes. One feature is to increase or decrease the slope of note velocities of a crescendo or decrescendo. The second feature is to increase or decrease the contrast of note velocities. The calculations were biased towards the first of the two features. A cresc or decresc needs at least two distinct note or chord locations. The increase or decrease cresc understandably does nothing if the notes are all at one location, i.e., they form a single chord. The second feature, increasing or decreasing the contrast of notes, piggy-backs the first feature; it borrows logic and calculations from the cresc/decresc command. If there is only one chord, then the logic throws up it hands and says it can't do this.

Well, so I tried fixing this, but after a half hour couldn't. This bug isn't worth spending more time, given other higher priority bugs that would take no more or less time to fix.

Sorry to say I won't fix this probably for a long time. Other bugs and features to work on.

Cheers
-- Mark

[NotationUser]

OK.

An alternative to clean this up "proper" would be simply not allowing to perform this operation on single chords

In other words check for at last two timing positions to enable the buttons.

Concerning chord progressions I will take a closer look over time again what happens here exactly...

As you say it's not a very high priority issue - it's just a bit odd when you try it unprejudiced.

[Mark W]

Hello NotationUser,

An alternative to clean this up "proper" would be simply not allowing to perform this operation on single chords

In other words check for at last two timing positions to enable the buttons.

That type of solution is very common among software programs out there. I think it is a bad solution!

It's a bad solution because there is no feedback. The button is disabled. The user sees that and wonders why? There is nobody there to tell him why the button is disabled.

The guideline in Notation products is that options are disabled only if it is intuitive to the user why they are disabled. Otherwise, the user can choose the option and then learn via a message, often in the status bar area, why the operation isn't allowed.

There is a work-around I could implement in Composer but, again, this problem is not sufficiently important for me to spend time on. I really shouldn't be spending any more time discussing this problem. But I can't resist.

If you copy/paste the single chord into three adjacent locations, and select all three chords then, as we know, the contrast velocity command works. You could do that work-around, and delete the temporarily added two chords but, of course, that would be way too inconvenient!

But Composer could do the same work-around behind the scenes, essentially duplicating the chord the same way, then apply the contrast velocity logic.

That's more insight into the internal programming of Composer than I only rarely take to effort to explain. But I thought you might find that work-around idea interesting. It would take me 30 minutes to implement, which is less time than I've spent in this forum thread ;-) I'll but this usability problem / bug back on the to-do list, with a note about the above internal work-around.

Cheers
-- Mark

[NotationUser]

I understand your opinion concerning user feedback.

However it looks like you are torn between reworking the algorithm to stay within your gui paradigms or spending the time for that on something else... I can't really help here, you have to decide... I don't want to push you doing anything either...

BTW - I think some feedback in the status line on the bottom is hard to notice too. I tried the practice feature today and wondered what was happening before the metronome click was to be heard... until I discovered that countdown in the status line on the bottom...

Maybe some feedback should open a separate box - also I understand that using the status line is simpler to manage.

[Mark W]

Hello NotationUser and Sherry,

Sherry, please help me remember, as it has been a long time since I remember having worked on this UI for error reporting. Does Composer sometimes show the error flashing the the status bar to get the user's attention? Or show it in red?

If that error reporting enhancement is already implemented in the released Composer (rather than in an interval version we've been working on), this please show me an example where the enhanced error is reported.

NotationUser, I agree that error messages in the status bar sometimes are noticeable. But what I really want to avoid is error message boxes always popping up that the user must dismiss, when the error is very minor, like "you can't move this note up a pitch because it would collide with another pitch." Imagine how annoyed you'd be having to dismiss that message box. If the note's pitch can't be raised, you'll wonder why, and if you wonder why, you'll soon learn to glance down at the status bar.

If there is a better way of informing the user about "can't do", then I'm not aware of it, and would be open to implementing a better UI for minor error reporting.

Cheers
-- Mark

[Sherry C]

Howdy guys,

The current error message implementation is this:

1. If Composer is going to ask a question or give an instruction, then there is a pop up box when the user does the 'wrong' thing. An example is clicking on the Text tab, then Special Symbols. The mode automatically switches to "Add" mode and is ready for the user to add a symbol somewhere in the score. However, if the user clicks on the "Special Symbol" button in the tool palette thinking that they need to click that first, an "information" message comes up, rather than a simple error message. These information messages typically have an "Ok" button to click them away when you're done reading.

2. If it is a 'simple' error message, the error message comes up in the lower left Status Bar, and the background is red for a few seconds, then the red fades away but the error message remains until the user either clicks in the score or performs some edit. An example here is trying to add a note in the score where a note already exists (eg. trying to add a middle C in the top staff in the same time position where a middle C is already in the staff.)

ttfn,
Sherry