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
