Decrease velocity contrast works odd

[NotationUser]

When I select multiple notes of a monophonic melody line along the time line the operations seem to work proper.

But wen I select a single chord with different velocities and apply "decrease contrast" the velocity values do not balance but increase in contrast. The option "increase contrast" affects the same change.

When I select more than one cord along the time line the operations seem basically to work somehow but the steps are coarse and weird.

Is this a bug or "a feature"...

[Mark W]

Originally Posted by NotationUser

But wen I select a single chord with different velocities and apply "decrease contrast" the velocity values do not balance but increase in contrast. The option "increase contrast" affects the same change.

The "decrease contrast" option for note velocity (loudness) is intended to contrast a series of notes. It wasn't designed for contrasting notes in a single selected chord. I could implement that, but this is a very specialized situation you're looking at here, that probably only one in a 1000 users would care about. So, I won't put this on the wish-list of many high priority items, unless some other users chime into this forum post and tell me they'd like this option for single chord note velocity contrast increase/decrease as well.

Cheers
-- Mark (the developer)

[NotationUser]

I was just surprised that it matters which notes are selected.

My expectation of "contrast" operations was something like you calculate the average velocity of all selected notes, then determine which ones values to increase or decrease and apply that incrementally by this operation up to the average value or the upper(127)/lower(0) bound.

Looking at it a bit more "complex" it's a kind of curve adjustment - like some midi filters or imaging programs offer with curves - here applied to midi velocity values.

Probably my main "problem" is I don't understand what you are really doing here and some explanation would help.

[Mark W]

Hello NotationUser,

For the upcoming v2.6.3, I'll try to fix this problem with note velocity (loudness) contrast not working. It should take me only 15-30 minutes to fix. (Task #2362)

The v2.6.3 release is expected in the next week or two.

Cheers
-- Mark

[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

[Mark W]

Hi Sherry,

That's funny. I looked at a couple of error messages displayed in red, and forgot that they were shown in red. And then I didn't even continue looking at them to see that the screaming red fades out after some seconds. Hey, that's a good UI, Mark (talking to myself).

But perhaps it could be improved by flashing something down there in the status bar to get the user's attention. Or maybe there is some other better way to further draw the user's attention to the error message in the status bar.

I'm open to suggestions here about improving the feedback to the user about "you asked me to do something that is not permitted" messages.

Cheers
-- Mark

[Sherry C]

Howdy Mark,

Originally Posted by Mark W

But perhaps it could be improved by flashing something down there in the status bar to get the user's attention. Or maybe there is some other better way to further draw the user's attention to the error message in the status bar.

I'm guessing that running lights around the perimeter of the Composer/Musician window might be a bit much?

ttfn,
Sherry

[NotationUser]

I've noticed the read bar but the font in the status line is quite small and black on red isn't well readable either.

Some of the operation methods may be well thought out when you frequently use Notation Software. However I must say some does not work like windows practice and one has to learn the differences...

Just some example about the mouse clicks: In windows one expects on right click context menus to open. In Notation Software I have to do a double left click while right click switches the insertion/selection modes. The two selection modes may be useful but the cursor does not reflect whether I am in region select or in normal select mode - so I have always to check that in the toolbar.