If the automation tracks are going to be collapsible, and then be sub-grouped
under the corresponding instrument- / bb-track, this will be awesome!
On 20. September 2014 10:29:47 MESZ, Vesa <dii....@nbl.fi> wrote:
]Ok, so here's again something I've been thinking about lately. And
]which, again, may or may not lead to things eventually actually getting
]done... ;)
]
]See, there's currently a sort of inconsistency in the paradigms of the
]different tracks. Instrument-, bb- and sampletracks all work with a
]"per-track" paradigm: each track is connected to one thing (one
]instrument, one bb-track, one sampletrack-fx-chain). Whereas automation
]tracks work with a "per-pattern" paradigm, where each automation
]pattern
]can individually be connected to different models.
]
]I'm starting to think it would be a better idea to have automations
]also
]work in a "per-track" paradigm. So that you'd connect a track to a
]knob,
]and then all patterns on that track would always automate that knob.
]
]Pros:
]+ consistency with other track types
]+ clarity: you'll know that a track connected to eg. "volume" only ever
]has patterns that automate "volume"
]+ ease of use: when you'd connect a track to a knob, you could then
]just
]add new automations on the track with one click of the mouse. Compare
]to
]current situation: you either have to clone an existing pattern (and
]maybe clear it if you want to do a totally different curve) or hunt
]down
]the knob you want to automate again and drag it to the new pattern
]+ most people use automation tracks in this way anyway, I think (see:
]clarity)
]
]Cons:
]- this might cause in some cases a need for more tracks in the project
](I don't see it as a big issue though, because again: clarity, most of
]the time it's better to use a per-track system anyway)
]- backwards compat might be a bit tricky to implement (should be doable
]though)
]
]This could also mean that we could discard the idea of a tempo track:
]If
]we make it so that each model can only be connected to one track, then
]it'll effectively mean that a tempo track could just be a normal
]automation track connected to tempo.
]
]There's also convenient features that could be implemented if
]automation
]tracks worked in a per-track way: something which Tobiasz (Unfa)
]suggested once is that we could draw the state of the automation as a
]line between the patterns so that you could always see the automation,
]and it could even be made so that the automation would be set at the
]right value when playing from mid-song, eliminating the need to "burn
]in" automations. This can only be done if automations work per-track,
]though.
]
]Opinions?
]
]------------------------------------------------------------------------------
]Slashdot TV. Video for Nerds. Stuff that Matters.
]http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
]_______________________________________________
]LMMS-devel mailing list
]LMMS-devel@lists.sourceforge.net
]https://lists.sourceforge.net/lists/listinfo/lmms-devel
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
