Hi all,
2015-03-21 0:48 GMT+01:00 Tim E. Real <[email protected]>:
>
>
> Please read through before responding. It is not all bad :-)
>
> "A lot of mistakes"? What exactly? Functional?
> This scheme, in its current form, looks terrible to me.
> Show me something better than this, or at least make it selective.
> Do not make it 'permanent' unless we can all agree and give it some time,
> we've been down this road before and I do not want to see the same
> mistake twice.
>
Yeah we were down this road (with what later became the Open Octave fork)
with a very much redesigned GUI which for various reasons turned out to be
a disaster. I'm not sure the disaster was so much for technical reasons
though, rather that we could not cooperate.
In truth I had all but forgotten about this dark chapter.
> The success or failure of this design depends primarily on one thing:
> Horizontal sliders.
>
Not sure I follow, did this come up before? If you mean they are a
fundamental part, I'd agree.
> Critique:
> --------------------
> Why would you completely strip away important visual cues
> such as the coloured track labels, meters, sliders, and icons?
> I have always have been against using 'letters', such a R S M for
> Record Mute Solo, in favour of icons. An icon contains more visual
> information than a letter, and is easily more 'international'.
This is devolution.
>
I agree, icons can be made smaller and still recognizable so they are in
many ways superior. Mute, On/Off and similar should stay icons, no question.
Colored track labels should also stay. It's a solid design choise.
>
> What's with the blue? Are there no other colours in his palette?
>
Thing is, for me muse's current gui is functional but it's not eyecandy.
Maybe some more color to this proposal would be nice but overall I kind of
like the streamlining of it all.
For the arranger I see the parts etc would have colors to contrast the rest
of the gui.
Look how wide those strips are.
> I have projects with dozens of tracks and takes. It is hard enough to see
> them all in our current strips, which are around 64 pixels wide.
> I am actually constantly trying to make them thinner!
>
Yeah, I saw they had grown in size, I think they should be thinner also.
I guess a counter argument is that computers are getting screens with
bigger displays. Tried a Lenovo Yoga2 pro laptop a while ago, it's got a 13
inch screen with a completely insane 3200x1800 pixels. With that much
screen estate on such a small screen it might be good with bigger strips.
But we are not designing for that, atleast not yet.
These new strips can't be made thin because they are using horizontal
> sliders.
> I studied the strip design, and that possibility, intensely after trying
> Ardour3 and talking to Paul about its design. Remember Robert we talked
> about plugin GUI sections for strips with changeable controls? That was
> part
> of the plan. Horizontal sliders were another aspect I studied. I concluded
> they were counter to the thin strips concept, the more thin they are the
> less
> accurate they are, both visually and user input wise. Yes, you can 'pop
> up'
> an accurate entry box when necessary, but that's /typing/.
>
Ah, I see what you mean. I guess you are right but they could be thinner
than this I think.
The good side of the sliders is that they can contain a lot of information,
since they are overlapping different types of info.
Keep in mind as well, our knobs are unique. I've seen a lot of designs and
> let me tell you, whoever designed ours was a freakin' genius.
> Want more accuracy - as you are adjusting them? Simply move out to a
> higher radius. Need a smaller knob - almost tiny? No problem, it self-
> adjusts to the layout.
>
Hehe, I thought it was you who did them? :D They are nice though I mostly
prefer adjusting with the scroll wheel.
>
> Granted, some information does not need to be as accurate as others.
>
> But, I'll point out that these new strips, even at a whopping 100 pixels
> wide,
> could not fully house our 128 integer step MIDI Pan horizontally,
> making it a hassle to adjust accurately.
>
Without a scrollwheel, yes. There might be a case for a zoom mode where the
slider grows bigger when you want to adjust it. But I see where you are
coming from, they might not be the solution for everything.
>
> *** See below, there *IS* a solution to this I realize now that
> I don't recall realizing before.
>
> What is meant by dockable? The whole mixer is dockable?
> Or the individual mixer strips are separable and dockable?
> I agree with this increased functionality.
>
I assume you were talking about my mail. There's another picture which
illustrates a redesign of the arranger where there are no popup windows.
> -------------------
>
> Suggestions:
> -------------------
> I can happily endorse such a design ONLY if a few conditions are met:
>
> 1) For Pete's sake, put some colour back in. This is not the Death Star.
>
> 2) Use icons where possible, not letters and words.
>
> 3) Do NOT increase the default strip width beyond around 70 pixels,
> which is the current width based on the default selected 10-point font.
>
> 4) To satisfy 3), you MUST design the horizontal sliders a certain way:
>
> Do NOT assign one horizontal bar pixel per adjustment value the way
> Ardour did! The horizontal bar must be 'detached' from the actual
> adjustment values and it must simply visually represent the value range
> stuffed into a small width.
>
Does Ardour really connect the values directly? Sounds fragile.
> How? Like this:
>
> As the user is adjusting the value, the actual /numerical/ value readout
> changes by an appropriate amount, say 0.01, but the visual bar does
> NOT move as much. That way we have full adjustment resolution and
> accuracy, while the bar simply approximates the current value.
>
In my mind that is the way it has to be. The volume slider on the mixer
strip, if you make it very short I believe it would only allow to make
quite coarse changes, simply because every pixel will represent quite a big
change. As I said I nearly always manipulate with the scroll wheel and
there's the shift modifier to make fine adjustment. Btw I added a similar
change to the automation editing. It's not as nice but it improved things I
think.
>
> But this presents a problem: Since it takes one mouse pixel movement
> to cause a value change of say 0.01, while the bar might not move at all,
> the mouse will move way beyond the bar position, making adjustment
> rather awkward as the mouse gets 'out of sync' with the 'leading' bar
> position (the bar's end).
>
> What to do?
>
> Use my patented "hidden borderless continuous mouse movement"!
> You can see that technique in the Pan and Zoom features of MusE.
> I have a lot of experience designing smart controls, and I have mentioned
> before that I have designed such controls using that technique.
>
> I will happily help design such a horizontal slider :-)
>
I'm sure we can find a working solution for that if we want to pursue this
redesign.
> Understand?
>
> Please, failure to adhere to these points, especially 3) and 4), will make
> a
> really bad mixer.
>
I'm with you on pretty much everything here.
> -------------
>
> I DO endorse Andrew's mixer changes.
> He reclaimed wasted space and filled it with something useful.
> BTW If the others agree I think you should go ahead commit your changes,
> give us what you got, it's OK we can tweak the knobs and sliders later,
> man.
>
For the short term I definitely agree. Those are nice additions and might
be the best way forward.
> Or, forget it and we go in this new direction...
>
For the long term I would not mind we rework the GUI, especially if Andrew
is willing to put in the heavy lifting. It's nice with a change and, let's
face it, it's good publicity.
I would _not_ sacrifice usability for looks though. All changes must be
designed for a reason and we need to feel it still works for it's purpose.
With that said, there is more than one way to skin a cat, what we have now
isn't the only solution.
Also, we can create as many branches as we like so nothing is really
stopping that some test redesigns are done, if it turns out bad we aren't
stuck in a bad place, we can simply abandon the test.
Sigining off, I'm extermely tired... I hope didn't express myself badly.
Let's keep the dialogue open if we want to try this.
Speak later!
Robert
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
