Am 03.02.2013 07:00, schrieb Tim E. Real: > On January 30, 2013 10:18:23 PM Florian Jung wrote: >> 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.
so you have saved and loaded a file? hrm interesting, i haven't touched this yet, so expect bugs there. but i'll have a look, thanks. > > ----- > 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. Four reasons: - work-in-progress and lazyness - the song position pointer and several temporary copies of it, as used somewhere in the audio thread needs the Pos be in FRAMES, not ticks. i tried with XTicks, and it broke: the song position moved too fast. - we need at least the frames() and lenFrames() functions anyway, and they must be kept. (because the audio thread doesn't care about XTicks, it wants to know the (current) starting frame. - PosLen has _lenType, which can be FRAMES. this is needed (or shall be converted into SECONDS later, but you get the point?), because i will allow unstretched wave events. They will have their beginning stored as XTicks, but always play back the same speed, regardless of the song length (for drums, effects and the like). > > 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. oh wow. i've not even thought of that. will need to go over there as well. > It's still early. I know you have TODOs in there. > I hope all the areas can be tackled. i'm sure :) > 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? Hrm, that might be useful for ambient sounds. It will be completely useless with everything having a "beat", however. Because then every attempt to stretch it would make it off-beat. (except by 50% and 200%). For MIDI parts, there is currently some function_dialog which does this. For Wave parts, there will be the "keyframe editor", which allows you to define the beats in an imported wave file (files recorded within MusE can be equipped with that info automatically). Inside this editor, you will also be able to do 50% / 200% tempo changes (this works by just manipulating the "beat markers" you or muse automatically put with the wave). For real elastic stretching however... hmmm that would be an interesting feature. I'll keep it in mind when designing the wave-restretcher, but I don't think we can do this too soon (problem: how do you handle if the user wants to extend the part (i.e., put more events in it, not stretch the rest?) > 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.) yup. I'm thinking about having individual part tempi. This would only be useful to movie makers, imho, so I suggest to postpone this until we have support for video. And i'm not sure if I want MusE supporting video... I don't like this featuritis, you know, do one job and do it well. If we are gonna do this, we might want to create a different program, which only handles video and audio, and additionally to some degree integrates with MusE (like directly reading and playing back .med files etc.) greetings flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
