The only counter point I could see is if some one wanted to implement math
interactions between automation tracks. AKA you create a "wave" in one
automation track and wanted it to add to or subtract from another
automation tracks "wave" to create a blend of the two. Currently new
automation overrides old automation so we can't do this anyhow, but if some
one wanted to implement a feature like this in the future it would be more
difficult.
On Sun, Sep 21, 2014 at 2:46 PM, Stian Jørgensrud <stian...@gmail.com>
wrote:
> 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
>
> > LMMS-devel@.sourceforge
>
> > 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
> LMMS-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lmms-devel
>
--
--Bill Y.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
