Re: [Rosegarden-devel] Best of both worlds branch is now up

[Tom B. (Tehom) <te...@pa...>]

> On 05/14/2013 05:32 PM, Tom Breton (Tehom) wrote:
>> I committed the "best of both worlds" merge on new branch
>> controllers-BOBW.
>>
>> I am particularly interested in Tim Munro's comments on it.
>

I'm going to answer the biggest issue first:

> In the not-so-minor annoyance department, I found the user-interface
> dialog absolutely bewildering.  It seemed to have little to do with
> expression controllers, and only after a great deal of trial and error was
> I able to work out what each item was supposed to do.  However, once I
> figured it out, I found the new features quite powerful.
>
>  From a programmer's point of view, the one-size-fits-all approach to the
> controller interface may be elegant, but from a user's perspective it is
> not.  For the sake of clarity each controller should have its own
> specialized interface dialog that clearly presents only those options
> appropriate to that controller.

OK, clear interface design is not my strength and I welcome help.

But all the options are available to all the controllers.  For instance,
you might apply vibrato to expression controllers; strings with expression
vibrato + modulation vibrato is sometimes useful.  So specializing on
controllers vs pitchbends wouldn't help.

Looking over the dialog, I see a number of places where the text assumes
pitchbends or is just unclear.  Let me run these possible renamings by you
and everyone else:

  * "Pre-bend" -> "Before Ramp"/"Before Bend"

  * "Value (%):" -> "Start at value:"/"Start at value (%):"

  * "Duration (%):"" -> "Wait this long (%):"
    * Tooltip: "How long to wait before ramping, as a percentage of the
total time"

  * "Bend Sequence" -> "Controller Sequence"/"Bend Sequence"

  * "Ramp duration (%):" -> "Ramp duration (%):"/"Bend duration (%):"
    * Tooltip: "How long the bend or ramp lasts, as a percentage of
      the remaining time"

  * "Preset" -> I don't know.  I can see where a user might not guess
    what "preset" means, but what's a better word or short phrase to
    convey the meaning?
    * Tooltip for preset: "Use this saved or built-in setting.  You
      can edit it.  For saved (but not built-in) settings, that will
      become the new saved setting"



> I've finally found time to look over this new branch and report back.
>
> I like the added functionality, particularly the ability to define a ramp
> over only part of a selected range.  In order to do that with my version,
> I would have to replace a note with a number of short-duration rests,
> select the ones I wanted, define the ramp, and then restore the original
> note.

I must humbly add that I only inherited that from others' work on
PitchBendSequenceDialog.

> Related to functionality I found only a few minor annoyances:
>
>    * When I highlight a note and insert a sequence of controllers, erasing
>      that same sequence leaves the last controller still in place.  I got
>      around that in my own work by placing the last controller back one
>      timing unit, so it would always fall within the boundary rather than
>      on it.

OK, easily added.

>    * The ability to select rests by themselves for establishing time
> frames
>      would be convenient.  This could be particularly useful when setting
> a
>      controller back to zero on a rest following a ramped note.

OK.  That's actually in the rc files, but I think I can change it around
so it's active when there's any selection, not just a selection containing
notes.


>    * If a ramp begins and ends at the same level (as when resetting a
>      controller back to zero following a ramp that doesn't end at zero),
>      there is no need to generate more than a single controller event.
>      The extra event is just clutter.

Good thinking.  I will test for that before placing the end event.

>    * The function "QSpinBox.setAccelerated(bool)" would be a useful
>      addition to spinBoxes, as it permits using a small step size for
>      precision, without requiring the user to wait forever for the thing
> to
>      crank around.

Good idea.  I hadn't previously known about setAccelerated.  I assume it
makes up/down arrows hyperbolic instead of linear?  We could probably use
that on a lot of dialogs.

	Tom Breton (Tehom)