>
> 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...
Preventing overlap accross tracks... seems like it would result in some pretty
> iffy usability as well - consider the situation where the tracks are at
> the opposite ends of the song editor. You try to move a pattern, and it
> gets stuck, but you can't see what causes it to stick... all you see is
> an invisible spot in the track you can't move the pattern to. Also,
> complexity and overhead of having to check through every automation track
> every time we move a pattern...
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.
I guess I just don't see the big picture of this change. The tempo
problem, well I hope we can all see the big picture with the tempo
automations and time travel. That is a programming nightmare. But the
knob automations... I still fail to see the benefits from my (humble)
perspective.
sure, if you mostly make some orchestral soundfont stuff or the like,
> automations are probably much scarcer there, but is that really what we
> want to pigeonhole LMMS for?
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. 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. :)
- tres.finocchi...@gmail.com
On Wed, Nov 19, 2014 at 3:20 PM, Vesa <dii....@nbl.fi> wrote:
> On 11/19/2014 09:24 PM, Tres Finocchiaro wrote:
> > I tend to use automations sparingly. When I do, I tend to use a
> > single automation track and just put small events in it where they are
> > needed.
>
> Well, here's another perspective: My projects can sometimes have
> something like 20 automation tracks.
>
> I'm surely not the only one. A lot depends on the type of music you make
> - many genres of electronic music rely heavily on modulation, sweeps,
> tweaking of parameters... Heck, the entire genre of acid house is
> entirely based on tweaking the knobs of a 303. Many genres of modern
> electronic music feature filter sweeps heavily.
>
> > Having multiple tracks using option #1 instead of the option #5 (keep
> > it the way it is) could be a visual distraction from a usability
> > perspective, but if it simplifies design I don't hate it.
> >
> > But I guess I'm not sold on the idea of what's wrong today.
>
> A lot of it comes down to usability. It doesn't even matter if there's
> lots of automations or not. Consider this scenario with just one
> automated control...
>
> Current situation: You drag a control to the track. A pattern is
> generated that gets initialized with the current value of the control.
> You stretch the pattern to, say, 8 bars, then construct a simple up-down
> sweep (4 bars up, 4 bars down). Now you want the next 8 bars to be, say,
> a double-speed version of the same (2 bars up, 2 down, 2 up, 2 down).
> You now have two choices: ctrl-drag the earlier pattern, then edit it -
> remove all the nodes and redo them, or move them about... or, ctrl-drag
> the knob all the way again to the track, then build the new pattern from
> scratch.
>
> Now, the first option isn't so bad in this example, since there's only
> two nodes in the pattern - but consider a situation where the first
> pattern is one you recorded live, with something like 60 nodes in it,
> which you have to manually erase. Oh, you could use clear pattern, but
> then you'd have to look up the end value of the earlier pattern and
> manually set the start value, if you don't want it to jump suddenly. The
> second option, ctrl-dragging the knob, isn't bad as such - nothing
> against ctrl-dragging the knob, as such... but when you have to do it
> constantly? It gets very tedious. You often have to keep the song editor
> maximized or at least sized very large, to be able to edit comfortably.
> This means the instrument where the knob you want is is always in the
> wrong place... under some subwindow, on the other side of the mdi
> area... you need to drag it close enough to the song editor - and woe if
> you happen to accidentally click on the song editor too early and lose
> the instrument window under it...
>
> Now then, consider the situation with per-track automation:
>
> 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.
>
> And that's just the beginning: we don't have to do the ctrl-drag at all
> (if we don't want to). We can just right-click the knob, select "add
> automation" and have an automation track appear, connected to the knob.
> We can do the reverse as well - easily disconnect a track, connect it to
> another control... clone a track, connect it to a different knob, with a
> couple clicks of the mouse.
>
> > What is is about automating multiple tracks in one automation track
> > that breaks our code scalability or increases complexity?
> >
> > Now, I get the whole "don't overlap"
>
> Well, but the whole "don't overlap" thing is pretty much impossible with
> per-pattern connections. You can always have two tracks, both having
> patterns connected to the same model... then you can also move them so
> they overlap, but on different tracks.
>
> Preventing overlap accross tracks... seems like it would result in some
> pretty iffy usability as well - consider the situation where the tracks
> are at the opposite ends of the song editor. You try to move a pattern,
> and it gets stuck, but you can't see what causes it to stick... all you
> see is an invisible spot in the track you can't move the pattern to.
> Also, complexity and overhead of having to check through every
> automation track every time we move a pattern...
>
> > But from a simplicity of design (or complexity depending on how you
> > look at it) what I've seen, 90% of the time, most people just want to
> > fade volume or pan. The other 10% is often edge cases that would
> > warrant a dedicated track.
>
> I don't really buy that... sure, if you mostly make some orchestral
> soundfont stuff or the like, automations are probably much scarcer
> there, but is that really what we want to pigeonhole LMMS for?
>
> Besides... if you only have a few automations, then what's the harm in
> having them per-track - to me it seems like it would only make things
> easier, with not much additional vertical space used (since there's only
> a few automated controls)?
>
> I dunno, to me it seems that the pros outweigh the cons by a fair
> margin, but maybe it's just me...
>
>
> ------------------------------------------------------------------------------
> 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
