>
> > I mean, how do we differentiate whether the user ctrl-drag-copies
> (already a cumbersome operation requiring at least two hands) a pattern
> because they want a copy of the pattern, or because they just want a
> pattern connected to the same knob to modify?
So the argument is that the average user is more likely to discover
automation via context menu, than from shortcut keys... Ok... I'm listening
now...
> I'm all for improving the pattern-copying functionality, but no matter
> how we tweak it, I don't think it can ever really offer the same
> convenience...
I think I get your point. We currently allow the automation pattern to
behave like a canvas before anything has been sent to it. Once it's
connected, the canvas is worthless. It's backwards from a workflow
perspective because we're giving users a default track to use that is
useless.
As far as the pattern-copying functionality, I think it's very intuitive
and a natural work-flow process. Perhaps my opinion is skewed, but I use
copy and paste more than any other function. The CTRL key has become my
best friend. I like the functionality of copying automation patterns.
There's also consistency. Every other track type in LMMS works per-track.
> Instrument tracks don't function as generic containers for patterns which
> you can connect to whichever instrument. Sampletracks contain samples that
> all connect to the same sampletrack fx chain.
Sure, but to be fair automation patterns are in a league of their own in
the context of "track" definitions. They control knobs, sliders and LCDs
that aren't necessarily assigned to any concept of a "track". This is why
I think the overlay (albeit complex to implement) wins. It puts the track
automation in the context of its own content. If done, I would expect the
editor could still be used for granularity.
I suppose perhaps I'm thinking about this too much from an architectural
perspective and not from a usability perspective. I expected some
technical limitations of the 2.0 rewrite to be the driving force behind
this proposal, but so far the arguments seem to be more about usability and
work-flow. I'm surprisingly happy about this, I just have some slightly
different qualms with existing usability that I won't go into detail in
this convo. :)
- tres.finocchi...@gmail.com
On Wed, Nov 19, 2014 at 5:43 PM, Vesa <dii....@nbl.fi> wrote:
> On 11/20/2014 12:15 AM, Tres Finocchiaro wrote:
>
> Will you hunt down the subwindow where the knob is, drag the window
>> close enough to the song editor, then drag the knob to the track, or will
>> you clone the recorded pattern and then spend time cleaning it up of dozens
>> of automation points - those are the current options, and either way is
>> cumbersome
>
>
> Thanks for explaining. Absolutely although I strongly feel this is only
> limited by the editor. I personally wouldn't use that as the basis for a
> drastic design change
>
>
> But it's not the basis on its own: there's also the second part of my
> post, the technical stuff...
>
> but I'm trying my hardest to offer my opinion (since that is what you
> asked for). So from that perspective, the editor could benefit from some
> enhancements which would make this limitation irrelevant (when we clone, we
> expect a copy, but we don't expect a bunch of trouble removing attributes
> of that clone, which IMO is the real inconvenience here).
>
>
> I don't think that really cuts it though. I mean, how do we differentiate
> whether the user ctrl-drag-copies (already a cumbersome operation requiring
> at least two hands) a pattern because they want a copy of the pattern, or
> because they just want a pattern connected to the same knob to modify?
>
> I'm all for improving the pattern-copying functionality, but no matter how
> we tweak it, I don't think it can ever really offer the same convenience...
>
>
> With the current situation, you either have to ctrl-drag a knob or
>> ctrl-drag a pattern. If it's a one-time thing it may not be a big deal, but
>> it all adds up in the long run.
>
>
> Thanks for explaining. That's what I thought you were driving at. I'm
> not trying to create an argument here, but, to your point... It too "adds
> up in the long run" on the flip side of that scenario. It's a preference,
> and it differs per user and I haven't seen enough reason to necessarily
> vote for one option or the other.
>
>
> Sorry, but I don't see how. What adds up? There's clearly less activity
> required... it's like putting down notes on the piano roll, or switching on
> steps on the bb-editor. One click, one pattern. The process is much more
> streamlined compared to constant ctrl-dragging.
>
> There's also consistency. Every other track type in LMMS works per-track.
> Instrument tracks don't function as generic containers for patterns which
> you can connect to whichever instrument. Sampletracks contain samples that
> all connect to the same sampletrack fx chain. All patterns on a bb-track
> trigger the same bb-track..pattern..thingy. Why should automation tracks be
> a special case? Why are they the sole ones that work per-pattern, when in
> fact automations are the only ones where overlap is an issue? Just seems
> entirely backwards to me...
>
>
> I simply fail to see the benefits of this proposed design from a
> usability standpoint. I am well aware that my opinion will always be
> slightly biased based on my usage (as well as the usage I observe from my
> peers)... but I think is the purpose of this conversation (when opinions
> are asked, there's no right answer).
>
>
> Oh definitely. I'm glad to hear your opinions always, even when they're
> contrary to mine. And none of us can escape our own biases, old habits die
> hard, etc...
>
> I just think if you could try the per-pattern workflow for a bit when it's
> all finished, you'd see the benefits of the model... sadly we still don't
> have that time machine :p
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> LMMS-devel mailing list
> LMMS-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lmms-devel
>
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
