[jur] wrote: ↑Sat May 11, 2019 7:34 am
Angstrom, you've already been quite vocal about the Browser for the past (8? or more ?) years and I'd personally be more interested in your opinion about anything else that the Browser, UI and workflow wise in the context of this thread.
well, of course I hate to harp on about the browser but it's the cornerstone of a multimedia app. Naturally if search, sort, and filtering is the intended method for finding our disparate content in disparate workflows then we might expect to see a bit more sorting and filtering on that search. Especially now that we have so many good UI patterns for search sort and filter because the
internet requires
them.
But I'll throw in a few quick UI missteps which occur to me.
These are more scattergun and what occurs to me in the moment, but hopefully illustrate the point
Macro / MIDI Mapping
With the mapping pane closed/folded - Right-click a macro-ed control in a rack and choose "edit macro mapping"
Expected: Macro/mapping pane open with the control focused.
Observed: Nothing happens, controls gain a background but the pane does not open.
Suggested: Pane shoudl open with selected control focused.
Key Mapping (UI divergence)
Put a Sampler in an Instrument Rack. Open both the Key range control of the Instrument rack, and the Key range of the Sampler. Set both to "large" zoom by using the contextual menu (!). Try to scroll horizontally in each
Expected: Coherent scroll method, EG: mouse scrolls horizontally.
Observed: They use different paradigms. The Sampler and Rack look very similar but the interaction is not learnable between both. They use a different metaphor (rack uses the Device view selector to scroll, Sampler uses the mouse hover over the note names )
Suggested: Improve zoom and scroll to remove contect menu and unify into a learnable zoom/scroll method for all range panes.
Devices GUI / UI (screen usage)
Wavetable - open and close the interface to and from full screen.
Expected: some kind of unified methodology of window-pane control, such as a key command or large window control to toggle full-screen view, and return to session/mixing view
Observed: a small marble 15px X 15px which must be clicked with a mouse, or the pane must be dragged from the top.
Suggested: A global mappable key command which universally toggles Devices into/out of full-screen mode
Presets(accessibility)
Most users will perform live and need some form of preset flipping, program changing, usually from a keyboard or external hardware device.
Expected: a method to move through a "set" of presets
Observed: no method to do so, other than the hacky "chain" method.
Sugestion: a method to do so which is coherent and logical, eg multi-select an arbitrary grouping of Instrument racks and put them in an indexable group with user assigned program change numbers.
-- many more of these available on request! --
These are all very "small" points, but my larger issue is that they have been left undone. Unfinished.
Wavetable is very forgivable as it's the first of (I assume) a new breed. But most other discrepancies have been in place for years. Eg: the range panes. Those things are brutal to use, and all of them work differently.
These are just a few illustrations not of "bug" or "wishlist" items, but of good features which never quite hit their 100% goal. They seem to have hit 85% and stopped. The "elegance" is missing.
That's where my BitWig comparison is equally relevant and also problematic. Their solutions for patching are slick, and look beautiful - but we can't draw direct correlations because of the divergent aproaches.
Ableton decied to go with integrating Max ... a 3rd party app which causes my Live to crash 8 times before every start. Ableton went from "you don't need a manual" to "oh, check out the JSUI code implementation we now integrate Node".
Bitwig decided to go with a bespoke solution. Bitwig went for "make a modular synths in 3 minutes".
Personally I strongly prefer the latter in a music making context. I do not want to take a reverb I coded onto stage and leak memory everywhere!
I'm saying that Live's Kitchen sink aproach to this decision is inelegant, and un-simple. Yes it's capable ... like a formula one car, but just like an F1 car it's very likely to break.
These issues of Live's ommision in finesse are difficult to illustrate because I could suggest "solutions" but they could easilly be dismissed as fanciful or unworkable. I could alternatively point at a competitors solutions, or solutions from other fields but these can be shown to be false equivalences, or having flaws of their own.
I feel that Live is a strong app still, but so many areas seem to have suffered from a lack of that last 10% of attention. And yes, I know the last 10% takes 90% of the time. Perhaps that's the issue.