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
