Re: [Qtractor-devel] Don't miss a chance to place ideas for automation
An Audio/MIDI multi-track sequencer
Brought to you by:
rncbc
From: Ralf M. <ral...@al...> - 2010-03-19 18:08:03
|
rosea grammostola wrote: > > > On Fri, Mar 19, 2010 at 6:47 PM, Ralf Mardorf > <ral...@al... <mailto:ral...@al...>> wrote: > > Rui Nuno Capela wrote: > > On 03/19/2010 04:20 PM, Ralf Mardorf wrote: > > > Hi Rosea :) > > IMO automation is less important, for me sync is much more > important and I also don't agree that cv is a good basis, > but the next thing Rui wants to approach is automation. > The Qtractor devel list doesn't need a second Ralf, it > still has got me. You now know that Qtractor does provide > some features you wish to have, but it isn't modular > enough for your needs. Join the list! Qtractor has got no > automation and take a look at the archive, > http://sourceforge.net/mailarchive/message.php?msg_name=4B9CDA7D.8050100%40rncbc.org, > automation is the current topic, don't miss to have impact. > > It's up to you ;) > > > > awe. > > let me tell you something about my plan. > > first thing, as it's currently /my/ plan and as stubborn as i > know i am, > odds are it will get implemented this way, one way or another :) > > automation in qtractor won't be any different than flagship > ardour or > any other late century daw kind. > > automation in qtractor will deal with recording, playback, > editing, > control and storage of selected track variables along the > timeline, like > volume/gain, panning, mute/solo and of course, plugin parameters. > > automation in qtractor will be tighly related to midi controller > mapping, so that each automation variable should have an > assignable > midi controller event type (cc, rpn, nrpn). > > big question in my mind is _how_ to store the automation data. > given > that last requirement, /my/ plan is doing it on plain standard > midi > files (format 1, preferably). just that, it might be ruled > otherwise, > all (delta) time units are expressed in frames instead of > ticks. or > whatever would please the sample-accurate crowd :) > > automation data resolution however, will be restricted to > either 7bit or > 14bit, being that a very well known limitation in midi > parameter data. > but remember, this just translates into a quantization effect > for the > stored data points (inflection points?). also, all automation > data is > ultimately converted and interpolated into a bounded target > data range, > usually float, but bounded ntl. > > under my humble horizon, i do find 7/14bit to be good enough > or even > pretty much than really needed :) it's just control data. > anyway, most > if not all of those data will be read/input from, uh, a midi > controller? > what else do you expect? > > just my 2cent;) > -- > rncbc aka Rui Nuno capela > rn...@rn... <mailto:rn...@rn...> > > > Sounds good, but you'd better ask Louigi Verona for feedback, he > started complaining about automation ;) > > Good luck with the project! > > \r Please take a look at Qtractor from time to time and give some input. For sure you are more comfortable with the non-family. ASAP I'll take a look at non-mixer and report Rui what I'm thinking about non-mixer. \ralf |