Decrease velocity contrast works odd

[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.