On January 30, 2013 10:18:23 PM Florian Jung wrote: > Am 29.01.2013 05:43, schrieb Tim E. Real: > > On January 29, 2013 01:09:15 AM you wrote: > >> Am 29.01.2013 00:29, schrieb Tim E. Real: > >>> On January 28, 2013 03:53:43 PM you wrote: > >>> Although it is early, one bug I noticed is that I simply imported a > >>> small > >>> > >>> existing wave file, and then the wave part's length was way too long, > >>> like hundreds of bars IIRC. > > > > Checked: It is after I moved the wave event in the wave editor, > > > > that the part length suddenly became 100's of bars long. > > fixed, was a design bug in schedule_resize_..._parts: it applied desired > frame length as tick length. > > > Also: Cannot move the red playhead cursor from zero :( > > Each time I click in the time line, the cursor goes back to position zero. > > Blue range markers OK though. > > fixed, was a mismatched }, which caused code to execute which would zero > the position. > > > > plus, PosLens (i.e. especially WaveEvents) can now have a start position > in TICKS, but a length in FRAMES. > this allows you to do effects or drums as wave events, with successfully > aligning them with tempo changes, but without stretching or clipping them. > > i made this the default for the moment, because wave stretching isn't > implemented (yet). this will change. > > please play around with the branch a bit, it should work fine, except > for loading and saving songs. > > greetings > flo
Still some problems: Here's the file (it contains KDE waves which might not be on your system). Maybe Robert's new missing wave file helper feature will work... http://dl.dropbox.com/u/53315356/Zoom-Test.med Here's a snap: http://dl.dropbox.com/u/53315356/pos_len_changes_1.jpeg The top half of the picture is how the parts should look. Top right shows an opened wave part with about a dozen multiple events, with one event selected (the thin black rectangle). The bottom half shows how it looks under the new branch. The part is too long and the opened wave on the lower right shows that the events themselves are too long, with one being selected the black selection rectangle is too long. ----- Had a look at the code a bit more. Can't comment too much yet. So I see as you say, that you replaced pos tick with an XTick (good), and made wave parts and events in units of ticks (good), but kept a TType for PosLen so it can be either ticks or frames length. Eh, why was that again? I think you said it was kind of temporary because we don't have any stretching yet? OK. Searching on FRAMES I see there's still a lot of places using frames. Like the PartList and EventList sorting and so on, just to name one place, although if all goes to plan, such places will later truly use only ticks. It's still early. I know you have TODOs in there. I hope all the areas can be tackled. As I say though, I fear we cannot eliminate frames altogether and rely solely on ticks and sub-ticks. One thing occurred to me: When a user resizes a wave part, should we have a mechanism which selects whether they want to stretch the contents as well? And conversely... would it be useful to do that to midi parts too? ie stretch or compress midi notes and positions, if the user desires? Hm, almost like adjusting individual part tempo, eh? (Hey, there's that term again... part tempos. Well, except here there's no tempos involved, just stretching of notes and positions. Just a thought.) Cheers. Tim. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
