On 11/19/2014 10:44 PM, Tres Finocchiaro wrote:
>
> You drag a control to the track. Now, the track is bound to the
> control, and you'll NEVER need to ctrl-drag that knob ANYWHERE
> during this project again. It's a single hole-in-one shot. Need to
> add another pattern? Just click the track, there it is,
> initialized with the control's current value. Ctrl-copying
> patterns still works the same.
>
>
> Perhaps I'm missing your point, but I still don't get it. Is the
> argument for automation track simplicity from
> a usability perspective? The example of recording and tweaking... I'm
> not sure how that is solved with the per-knob proposal? I think I'm
> missing something here...
What was unclear about it? Compare the two scenarios I laid out, the
usability patterns of each case. With per-track automations, you can add
new patterns that are automatically connected to the model you want,
with just one mouse click. 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.
The recorded automation pattern is just an example of typical use case.
You have recorded an automation pattern, now you want to create a
different pattern but manually this time - but connected to the same
knob. So: 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... especially compared to just a single click
on the track.
And the thing where you can add an automation track automatically to a
knob by selecting it from the knob's context menu - that kind of
functionality would be tricky to implement with per-pattern connections:
where do the patterns go? Should a new track be created? How to decide
which position to put the patterns in? With per-track, it's just a new
empty track that's created, and you can then just single-click your
patterns where you want them. Convenient.
It may not seem like much when explained in text form like this, but
when you try it in practice, the difference is night and day. I'm
actually still a bit in awe how simple and easy it feels to just click
away on a track to create more patterns.
> No, I don't think we're on the same page at all. I was speaking about
> the overlapping of patterns on the same track, not separate tracks.
> Just the fundamental design of the song editor in general, which I
> believe was proposed at one point in time. I wasn't trying to suggest
> that one automation track is cognizant of the others.
Well, there's the problem... say you have two overlapping patterns,
connected to the same knob. What happens when you play the song through
those patterns? What happens to the knob? Can you say?
I can't. Neither can LMMS. You can try it right now... two overlapping
patterns (on the same track or on different tracks) results in undefined
behaviour. Realistically, it probably depends on the order they get
processed, but there's no way for the user to see that, so no one can
predict which pattern gets applied to the knob. For the user, it's
ambiguous.
So that's bad. But that's again just the UI. Let's get technical... say
we want to parallelize the processing of automations (they're currently
not). Let's also say we want to have the automations get processed early
on, so they can eg. render and provide accurate sample-exact data to
knobs that require it. Now, if we allow overlapping automations to the
same knob, that won't work - we get race conditions, so then we need to
protect the access with locks, to prevent both automations accessing the
model simultaneously... see where I'm going with this? Locks, bad RT...
> If I gave the impression that quick overlay automations would be a
> replacement for automation track, I'm sorry, that was not the
> intention of the idea. It was simply a convenience feature for the
> more mundane automation tasks. I don't believe it would pigeon-hole
> the software at all.
No, I get that. I only meant that if we assume the users only want to
use volume/panning, that users don't need to use many automations,
that's where we get pigeonholed... we should make it convenient to use
automations in any quantity, and per-track allows much more convenience
when the amount of automations scales up - when you have lots of
automations, you'll want to have them organized per-track anyway, and
then it just seems pointless labour to have to keep ctrl-dragging all
the time when you know you just want the same knob on the track.
> But this over-lay automation concept is well illustrated in plenty of
> other track-editing interfaces which I'm sure everyone is familiar
> with, so I don't want to beat-up the topic too much. It's just too
> often that when I do need an automation, I can't see the material I'm
> automating over. An overlay in the automation editor could help in
> this regard, but then it's quite the same implementation anyway. :)
Oh sure, overlapping automations over patterns could be a neat
feature... it's just that the technical side gets a bit blurry here - if
we need to prevent overlap, then each knob can only be connected to one
source of automation, so then we would need to have some kind of
"embedded automation track" within the instrument track... kind of like
how we have embedded automation patterns for notes.
Still, I think it could definitely be something we could look into and
assess in the future.
------------------------------------------------------------------------------
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
