So, the only thing you are saying is that it is easier and more logical this way, and I agree, it is. Go ahead and do it :) Cause consistency is the keyword here? I can't see how this will solve any bugs?
diiz 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmms-devel -- View this message in context: http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Let-s-rethink-automation-tracks-tp10416p10429.html Sent from the lmms-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
