On 05/25/2014 03:25 AM, Tres Finocchiaro wrote: > > Tempo automation track is still a track and should operate as a track. > > This means it should be consistent with other track behavior: > > 1. It should be removable >
This can be achieved with a show/hide function. > 2. I would advocate that it is not part of the default song editor > template > Disagree, it's important for discoverability that the tempo track is visible by default, especially since this is new functionality. > 3. It would have its own button. > Button? Button to do what? Explain please. > All that I am saying is that if a tempo automation track is > essentially a dedicated track which automates tempo, then we should > consider making a catch for the old behavior. > Right, but just explain to me what exactly is it that is supposed to happen when you drag a knob to an automation pattern. Will the automation pattern just leap into the tempo track, will it be copied there, will the entire track be copied, or what? > The old behavior isn't some silly old way of doing something, it is > the logical way to add a knob or slider control event to the DAW. > This isn't just to appease old time users or those reluctant to > change, but rather a common sense courtesy to the interface. > Well no one is saying it's silly, but if we're going to make it so that tempo is a special case, then it kind of no longer makes sense to drag the tempo widget anywhere. There are other widgets that can't be dragged. Graph widgets, tool buttons... > How I described it working (by replacing the automation track) is > probably unintuitive, but I see no harm in leaving the drag behavior > and making it a shortcut to the new behavior. > But the way you described it working doesn't make sense. The point of the tempo track is that there is *only one* tempo track. How do we "replace" the automation track - what exactly is supposed to happen there? Replace it with what? The existing tempo track? > The infographic is humorous. I deal with this mentality all the time > and find it quite funny, but in all seriousness, keeping the tempo lcd > draggable has its merits. > Sure it may have merits, but it's not always a matter of merit only... sometimes we have to consider whether the gained benefit is worth the added complexity. Especially since you have to consider that every feature we introduce must be maintained, must be tested, fixed... and it'll affect all future features, which need to take it in account - more complexity means more things to take in account when planning future features. So especially with our limited resources, it kind of always has to be a cost/benefit analysis... > I would say take it a step further and allow any > knob/slider/lcd/toggke component to be dragged directly onto an empty > bb/song editor slot and create the appropriate automation track for it. > Yeah that could be done but that's a separate discussion... ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
