Hi Florian, 2013/11/7 Florian Jung <[email protected]>: > Hi Tim, Hi list, > > Do we have any ideas on how to deal with automation in the future? > > With my recent changes, we must support both tracks which have the > automation stored in TICKS, and tracks with automation stored in FRAMES. > > I really want to be able to keep my MIDI automation with my MIDI parts, > because i often consider "the controllers" and "the music" as one unit, > which must be moved around together. > > Same thing should exist for audio, btw!
Very true. > > But then, I also want to have automation which is per-track. For > big-picture-crescendos etc. > > > I have some not-well-considered thoughts: > > 1. each part has automation (also audio parts); each track has > automation, and both "sum up" to the effective value used. > > contra: complicated, not very transparent/intuitive > > 2. automation is *only* stored in the tracks, not in the parts. > but in the arranger, offer "move part but keep automation in place", > "move part and move automation with it" and "move and copy autom.". > > this should be done with something like a checkbox each part carries > around. > > contra: change in the file format. importing will lose information. > pro: intuitive. avoids the "concurrent automation" problem. > pro: no more need for that weird MidiPort-housekeeping for rapid > controller changes upon seek; because now there are at most a > couple of tracks to consider, we can just iterate through all > of them, right? > As most of the time this boils down to what is possible to implement without breaking more than you fix.. Both solutions have merit.. I actually don't know how other softwares do it. I think the first alternative feels very clean and easy to explain. Though it might not be so easy to use. How to select if editing the track or the part for instance? Instinctively I prefer 1 but maybe 2 will win out in the end. Will have to think some more on this. Regards, Robert > > just some thought, please add your 2c. > > This will become a blocker for me in the future, because at some point > it influences how time-locking parts will be implemented. > > > Please reply, > flo > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Lmuse-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
