Sorry, accidentally sent a half-written mail there. On Wednesday 18 May 2005 11:11, Guillaume Laurent wrote: > On Wednesday 18 May 2005 10:59, Chris Cannam wrote: > > On Tuesday 17 May 2005 08:00, Guillaume Laurent wrote: > > > On Monday 16 May 2005 22:17, Chris Cannam wrote: > > > > I'm sorry, but that's just weird. [...] > > > > > > Does it ? I thought it looked ok... > > > > No, sorry, it's just weird. > > OK, feel free to revert it then, right now my version of > compositionview.cpp is in a non-compilable state due to me trying to > get the audio previews in (much harder than I thought).
One thing to remember for audio previews -- that will either make things really difficult or possibly slightly easier, but will certainly make them really difficult if it isn't thought about in advance -- is that our main timeline is "musical time" whereas the audio previews are "real time". The ratio between audio preview pixels and on-screen pixels will vary depending on the current tempo, and this may change during an audio segment, so the segment previews will have to stretch and squash accordingly. The trivial way to do it would be just to convert the real time to timeT for each of the peak frames (using the Composition conversion methods) and then convert time to X for each using the ruler scale. Unfortunately the Composition part of this is way too slow to do for each peak, so we'd have to distribute peaks evenly between tempo change points instead. (FWIW we fudge this entirely in 1.0 -- the audio segments are wrong in any situation where they overlap a tempo change. 1.0 just distributes peaks evenly throughout the width of the audio segment. This is something we really need to get right in the rewrite though.) I can probably handle audio previews myself if you like, or at least give them some thought, but my time is pretty tight at the moment as well (I'm also working on a bunch of things at once) so I can't promise any particular timescale. > > Surely all it takes is to draw the box background first, then the > > previews with those pixels within the box appearing in a fainter > > colour, and then the box outline and the text. > > The way the drawing code is currently designed doesn't make it that > simple, and doing it that way would turn it into a big mess. So you _are_ a wuss! I knew it. > Translucency will have to be done at the X level. Oh nonsense. What a waste -- demanding translucency support at the toolkit or server level just for the sake of drawing one poxy little label. Honestly. > Yes. BTW, if you had a few brain cycles to spare on helping me solve > this : > > https://sourceforge.net/tracker/index.php?func=detail&aid=1184540&gro >up_id=4932&atid=104932 > https://sourceforge.net/mailarchive/message.php?msg_id=11661650 > > I'd be most grateful. I'll try to find a few. Bit in the middle of something right now though. Chris ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
