Am Thu, 6 Aug 2009 12:50:02 -0500 (CDT) schrieb "Gabriel M. Beddingfield" <gabr...@teuton.org>:
hiho gabriel :-), > Hi guys, > > Jakob and I were talking (in a different thread) about the transport. One > of the issues that came up is lead/lag scheduling, and I would like to get > some more opinions on it. > > IN THE DISTANT FUTURE[1], I would like to be able to precisely set > lead/lag settings by: > > a) ticks (so that the timing changes with the tempo), OR don't know how this will work. ticks have a really big resulution and in moment we use 192 ticks in 4/4 or 48 ticks for every 1/4 beat. if leadlag works with ticks we can remove the whole function. why? if i disable the grid in patterneditor, i can edit notes on every tick in a pattern. this method is much easier as slide into the leadlag note property's. so, imo we need no lead lag if its based on ticks. because this lead lag resolution is not fine enough and there is a more easy way to edit this as the leadlag slider. maybe here its a good idea to raise ticks up to 420. than we can divide grids in tuplets 5 and 7, triplets 3 and normal 4. and also the ticks based lead-lag resolution is smaller. > b) milliseconds (so that the timing DOESN'T change with > the tempo) > And, I would like the ability to set these on a per-note (or > per-instrument) basis. > > On the back-end, I would like to convert the milliseconds to ticks. Which > means that we won't schedule it right whenever a tempo change happens. > This will potentially affect a 100ms zone of music where the millisecond > lead/lags aren't quite right.[2] > > What do you think? Is this good enough? Or would you like the > milliseconds to *always* be honored?[3] Or is the whole idea overkill? > :-) > > Changing this later (if we change our minds) will take a lot more effort. > > Peace, > Gabriel > > [1] That is to say... yes, figuring at the UI on this one > looks tricky, but I at least want the back-end tools > to exist if we ever add this to the editor. > > [2] If tempo is 80 bpm and a note has a 100ms lead, but > the tempo changes to 180 bpm after scheduling the note, > it will sound with a 44ms lead. > [3] There could be a few cases where a tempo change will push > the note out before frame 0... and of course, there's > nothing we can do about that, so they'll get cut short, > too. in moment this is a problem with trunk transport. and not only on frame position 0. its a problem on every bar. if tempo changes on pattern tick position x, all notes exactly in change position will sometimes played twice. this happens only if tempo change from high to lower values. audioEngine_updateNoteQueue( nFrames ) will triggert two time the same note. because audioEngine_process() do a audioEngine_process_checkBPMChanged() in each cycle just before audioEngine_updateNoteQueue( nFrames ). important! this is independent from jack transport functions. you see what happens here. the ticksize change and also the frameposition for the just played note. now audioEngine_updateNoteQueue( nFrames ) pusch back the same note twice into the NoteQueue. next problem is the lookahead function in audioEngine_updateNoteQueue() here h2 goes out of sync if tempo change. i play around with a internal h2 tempochange function (time line). here i get massive problems with sync if m_nLookaheadFrames are different than buffersize value?! nLookaheadFrames = buffersize will bring the best sync results at tempochange. as you know i have implement a simple timeline in fx and sample fun. here i found this problem. last year i build a similar time line function into rev85. rev 85 is without leadlag. into this version i have less sync problems. and no double hits if tempo change from high to low. what ever. this is off topic, but imo, for the 0.9.4 release maybe a look into the lookahead function is no bad idea. wolke > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hydrogen-devel mailing list > Hydrogen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hydrogen-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hydrogen-devel mailing list Hydrogen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
