On January 2, 2013 11:33:00 PM Florian Jung wrote: > Sorry for the spam, > > i just noticed that the TICKS vs. FRAMES issue sucks even more than I > was aware of. > > When i draw automation for a software synthesizer, this automation curve > is stored in FRAMES. So when changing tempo, all my automation is > screwed, even though it would be perfectly fine to "stretch" it (i.e., > have it stored in TICKS, not in FRAMES) > > We'll need to overhaul that soon… > > My idea is: > > - don't store any beginning points in FRAMES, only TICKS > - (wave event beginning offsets are still stored in file-relative > frame counts, but that's different) > - store all automation in TICKS > - wave parts may select one of "store length in TICKS, auto-stretch" > (suitable for recorded or played-in music) and "store length in > FRAMES", do not autostretch (suitable for effects like screams, door > creak etc) > > problems with that: > one might have meant to modulate an "effect" like a scream, door creak > etc with the automation. This would break now. (but this currently > breaks as well: you'd have automation and the effect in sync, but not > effect and music; i think the change even makes it better.) > workaround: modulate your effect outside MusE and use that modulated > wavefile. > > > FRAMES are basically useless, because they're sampling-rate dependent > (which both tim and me want to fix by doing transparent sampling rate > conversion) and tempo-dependent (which at least i want to fix by > time-stretching audio). They're good as a "slave", cached quick-lookup > data, but they must not contain information. > > i think, all FRAMES stored within MusE should be calculated from TICKS > values, and never vice versa. > (The only exception might be wave event length for effects) > > greetings > flo
Whoa hold on there. Frames are for all things audio related including audio automation, because these things need to be sample-accurate. Frame (sample) -based timing and editing has no concept of Bars, Beats and Ticks. One can only convert between frames and ticks. When all you have is ticks, convert them to frames with the tempo map. You lose frame-resolution, but you can't do any better than that. Deriving frames /always/ from ticks, throughout MusE, is a BAD idea. Trust me you do not want to do that. You must convert from ticks to frames and vice-versa where necessary, and our code has plenty of functions to help with these conversions. Your particular usage may require it, but not all of MusE. Yeah I know, there are tough challenges with this duality. In the end it all comes down to what *mode* the user wishes to operate and edit in: Bars Beats and Ticks mode which is tempo-based, and frames (samples) or SMPTE mode, which is linear and has no concept of tempo. Someone who works in television will want linear time mode. They have *no* use whatsoever for tempo based BBT mode. Also in theatrics and staging for example. These folks will want midi controllers - but in linear time mode with no tempo ! Being able to operate the Arranger, the Pianoroll, AND the Wave Editor in *either* mode, at will, is *crucial* to achieving these goals. Recall in my latest branch I'm attempting to radically overhaul the time-lines and ticks versus frames and positions etc. You are starting now to see some of the reasons why this needs to be done. I know /all/ the problems related to ticks and frames. Ask if you need some help, I'll try to answer as best I can. My latest branch will, if ever completed, address some of these problems. I recently got over some hurdles there and need to tell you exactly what to do, with example areas done and so on, if you want to help. I believe we can proceed with /some/ confidence there now. It's just a big job, many areas to do, and has to be extremely carefully done, we must be at the top of our game when touching each area, and may result in discoveries that require further re-writes to my changes and concepts and so on. Recall I said in my branch that ticks versus frames is much more agnostic. It allows easily switching from BBT to Frame mode at will, in all windows. And yes, audio and midi controllers I later realized also needs to be re-done to support this agnosticism because one is frames and one is ticks. That'll be a tough job for sure. --- About automatic 'live' wave part time-stretching, without rambling on too much, here's what I concluded about /my/ system: (My system could re-sample, pitch shift, and time-stretch on the fly. Hedging my bets on which library is best, I'm trying to make the classes to allow new types of converters to be derived when they appear on the scene. I've definitely got SRC for re-sampling, and was working on RubberBand support at last stop. There's a few more new libraries out there I'd like to try.) When a wave is added or recorded in MusE, the wave event will need a to store with it a 'snapshot' of the complete tempo map at the moment the wave was added. Each wave event will need this tempo map 'snapshot' hanging around so that any *further* changes to MusE's tempo can be *compared* to the snapshot and the time-stretcher can know exactly how much to stretch based on the differences between the snapshot and the main tempo map. Without these tempo map snapshots we are dead in the water I believe. Yeah, I know, tons of stored data possible... Can't think of a better way. Since tempo maps can store tons o' data, I had an idea before, to store them in separate files instead of the .med file. (Similar to your question.) Further, since audio controllers can also contain tons o' data, I propose we allow them also to be stored to separate files. And anything else that could contain tons o' data. Think about it. It's all floating or integer data, at audio sample rates. So make it a wave file ! Thus MusE could read and store wave files - as audio controller data ! Anyway, further influence on the stretching could come from some audio automation controllers. Also, controllers could also govern some pitch shifting curves, and even be midi note-driven to act as a sampling instrument. Got a disk. Installing BSD now... Tim. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
