Hi All,
As for me, I like the dockable ui concept very much. Not only because
it
will save space and look more uniform, but also because any docked window can
be undocked with one button, so the entire gui style can be made switchable
via a menu option (the current style can be preserved!)
What about the new look offered by Budislav (now I will expose only my
point of view) - the main advantage is that all gui controls are consistent
and form a smooth picture. May be colors can be made more lighter or so (I'm
not a designer, so can say only what I feel, but not the way how to implement
it) and text buttons can be replaced with image buttons. But anyway I like the
idea :).
Now I can't start to implement it because all of us must achieve common
opinion of how the interface should look like. If Budislav has a free time and
a wish to continue, may be he can implement Tim's point of view? I think that
it can be done.
Regards,
Andrew
> On March 19, 2015 07:52:41 PM Robert Jonsson wrote:
> > Hi folks.
> >
> > Andrew, I saw you responded on the ticket that you would like to work on
> > implementing Budislavs proposal. :) Just thought I would bring it up here.
> > Tim, it would be good to have your opinion also. Others are of course also
> > welcome to give an opinion as this could be a big change.
> >
> > Personally I think the style Budislav has come up with is very nice and I
> > would have nothing against changing the gui to look like this. Tim, I know
> > you have worked on a lot of the GUI previously so you have a big say in
> > this. What do you think about it and does this come in the way of
> > something
> > you would like to do?
> >
> > As I wrote previously, Budislavs ideas about changing the GUI to use
> > docked
> > windows is the most controversial change and this really merits some after
> > thought on what the idea is and how one would it. He may be right that the
> > current design makes no sense, it is a traditional approach.
> > I will try to find time to think about this myself..
> > One thing I thought of was the midi editor in a docked window, how would
> > that work? Would there be only one possible view or would there appear a
> > new tab for each open midi editor. If there is only one I guess that one
> > would change to the content of the currently selected part. Maybe that is
> > a
> > good thing but it sounds like a major of the editor. I might be over
> > analyzing this :)
> >
> > All for now!
> >
> > Regards,
> > Robert
> >
> > 2015-03-19 8:44 GMT+01:00 Robert Jonsson <[email protected]>:
> > > Hi Guys,
> > >
> > > I was meaning to forward this earlier.
> > > Budislav did some very nice looking work for ZynAddSubFx earlier and now
> > > has taken up redesigning the GUI in MusE.
> > >
> > > The mixer view is very nice looking I must say. His redesign of the
> > > entire
> > > workflow takes some more thinking before I understand it so I can't say
> > > if
> > > it is a good idea.
> > >
> > > If anyone is interested, do take a look. As he stated, if noone is
> > > interested in implementing his graphical redesigns there is not much
> > > point
> > > to this exercise.
> > >
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: budislav <[email protected]>
> > > Date: 2015-03-19 5:45 GMT+01:00
> > > Subject: Re: [muse] completely dockable UI, multiple view presets (#345)
> > > To: muse-sequencer/muse <[email protected]>
> > > Cc: spamatica <[email protected]>
> > >
> > >
> > > Fully redesigned mixer. I noticed a lot of mistakes in this particular
> > > window and tried to fix everything. Same mixer but pro look :)
> > > What do you think?
> > >
> > > New
> > > [image: mixer]
> > > <https://cloud.githubusercontent.com/assets/3619927/6724456/9c8e96c8-cdf
> > > 8-> > 11e4-8c34-eb664d3e3a7c.png> Old [image: mixer old]
> > > <https://cloud.githubusercontent.com/assets/3619927/6724458/a2029e92-cdf
> > > 8-> > 11e4-85ed-c0112a40b47f.png>
> 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.
>
> The success or failure of this design depends primarily on one thing:
> Horizontal sliders.
>
> 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.
>
> What's with the blue? Are there no other colours in his palette?
>
> 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!
>
> 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/.
>
> 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.
>
> 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.
>
> *** 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.
> -------------------
>
> 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.
> 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.
>
> 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 :-)
>
> Understand?
>
> Please, failure to adhere to these points, especially 3) and 4), will make a
> really bad mixer.
> -------------
>
> 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. Or, forget it and we go in this new direction...
>
> Thanks for listening.
> Cheers.
> Tim.
>
>
> ----------------------------------------------------------------------------
> -- 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
------------------------------------------------------------------------------
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
