The problem is that time-signature changes were an afterthought in LMMS. When you change timesignature, it causes all the events to be "remapped" to the new timesignature. This causes the weird offsetting and other issues.
The solution is for LMMS to store a proper structure containing all tempo and meter changes. This way, the editor can display these changes, and even use different grid sizes depending on the time signature for that section. I implemented this structure a few months ago, but found that it would basically require a rewrite of LMMS's core in order to properly integrate the fix. The bad news is, this will take "a long time". The good news is that I'm actively working on a core rewrite now, which will hopefully eventually become the default for LMMS users. A temporary solution is to devise a time-signature which contains all your "target" time-signatures as factors. I.e: the global time-signature is divisible by all your "logical" time-signatures. You will not change time-signature in your song, instead, you can use different note durations. -Pau; On Mon, Mar 22, 2010 at 2:57 PM, Tommy Raz <[email protected]> wrote: > I was coping with strange grid lines in the piano roll in 0.4.2 and then > updated > to 0.4.6 and still seeing them. I'm doing progressive rock genre work, so I > deal with weird time signatures. > > Try this in piano-roll: > Paint some 8th notes repeating on 1 key across a couple of measures. > Looks great, notes and grid lines are aligned. > Now switch time signature to 3:4, still looks good. > Now try 6:8, still good. > Now try 7:4, good. > Now try 7:8, on my system the grid is off. Is it just me or does this happen > with other people's systems? > > Experiment with various x:8 and maybe you'll see that some look good and > others > are off. > > I know it's just a cosmetic issue, but it's confusing enough to make me avoid > certain time signatures. > > So I am wondering if this is related to integer/float stuff in the code. > > For example, in piano_roll.cpp, notes begin at > ( pos_ticks - m_currentPosition ) * m_ppt / midiTime::ticksPerTact() > > So we get an integer position scaled by a float formula. > > Whereas the grid lines ("vertical raster") are incremented in a loop by a > pre-scaled float pp16th > which is m_ppt / spt > which is m_ppt( DefaultPixelsPerTact ) / midiTime::stepsPerTact() > > So I wonder if the vertical rasters from the for loop might match note > placement > better if it incremented by an integer amount then was scaled afterwards to > get > the position for the lines. > > It's just a guess. Maybe there's something about the difference between steps > and ticks, I dunno. I don't have my system set up to compile this and see for > myself... yet. I'd like to try that, but thought I'd throw this out to you > all > in the meantime. > > Any thoughts? > --Tommy > > ps: If any of you are curious to hear prog-rock composed by lmms, reply and > I'll > send you the link (it's work-in-progress so don't want to broadcast the > versions > we have so far). > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > LMMS-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmms-devel > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
