On January 3, 2013 07:50:34 PM Florian Jung wrote: > Am 03.01.2013 02:41, schrieb Tim E. Real: > > 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. > > what about sub-ticks? floating-point ticks?
A tick is the minimum unit. > > > 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. > > please tell me more: what usages require samples? > > > 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 ! > > hm; true. but in that case, our current concept is still broken. these > people don't want any ticks then, right? they want MIDI to be stored in > samples, as well. Yes. That would be a goal. Both midi and audio events aligned to either ticks or frames. > > > My latest branch will, if ever completed, [...] > > can I help? > anyway, please tell me what you're trying to accomplish exactly. What's > the new concept? No time to go into it now but I posted a few really detailed messages before. Take a look at the file ABOUT_THIS_BRANCH in the branch. It explains everything in detail and shows where the branch is currently at. > > > [...] RubberBand [...] > > > > There's a few more new libraries out there I'd like to try.) > > RubberBand sounds interesting. Sample-exact stretching is particularly > cool; SoundTouch would need further tweaks before one could do this, > RubberBand is better there probably. > > But I doubt that it can cope with libsbsms. libsbsms does a *REALLY* > good quality. Not really usable while editing your piece (my core i5 can > only process 1-2 tracks in realtime and is fully loaded then), but good > for finishing (imagine a "draft" and one "final" mode) Yes, all these converters take a lot of processor time. When I had the SRC code running, just a few tracks were enough to slow my machine down. Similar to adding OGG or FLAC files to MusE. I mentioned these take up a lot of time too. > > > 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. > > exactly. Or it can store a *different* tempo map, that is what i meant > with my "tapping" suggestion: > Imagine you have a wave file which does not fit your tempo. Then just > store the *appropriate* tempomap with it and it will be fine. True. When recording a wave in MusE then the tempo map at that moment is its tempo map. But when importing some wave it might not have consistent tempo, or changing tempo, so I guess you're right, one would need to either tap the tempo out or have something automatically try to determine its tempo(s). > > > 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. > > full ack. > > > 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 ! > > hrm, yea... wave files are imho not good for tempo data or the like: we > have relativly rare tempo changes (as opposed to 44100 tempo changes per > second). Mm, not quite so in at least one case: Since I added tempo recording during external sync, this can produce a lot of tempo data. For the utmost synchronization accuracy when playing back audio and midi after this tempo recording, the data cannot be averaged or smoothed otherwise drifting will occur. However, I did add several averaging options in the Midi Sync Settings in order to reduce the amount of data. External midi clock is very jittery and tempo is derived from it. If no averaging is used at all the tempo jumps all over the place. The choice of averaging depends on the situation. If one expects a single solitary consistent tempo from the external device while it plays, then heavy averaging can be used and produces very little data - usually just one data point despite the extremely jittery nature. OTOH If one expects changes in tempo or sudden changes in tempo, there are several other averaging settings to deal with this. Ultimately if one expects to record audio and midi while externally syncing, the averaging should be completely turned off, for the utmost audio/midi sync accuracy on playback. You'll see the resulting tempo map is very jittery with values all over the place, at near-audio-samplerates, but really this produces the most accurate results because it is an exact copy of the exact actual tempos that arrived. > but i agree that we might want to split the file format: however, i want > to still have one file. we could tar it all together. True. Robert pointed out that we /do/ allow compressed .med files so perhaps all these file separation plans could be a moot point, perhaps all large data could still be put in the .med file. But, meh, I think I would still prefer some separations in some cases. > > > Anyway, further influence on the stretching could come from > > > > some audio automation controllers. > > how do you imagine that? i don't think we want stretching in automation, > because it is hard to map. Er, well, I just meant the user might want to manually have some influence on the stretching. ie purposely slow it down or speed it up etc. > > > Also, controllers could also govern some pitch shifting curves > > full ack. i think MusE should offer this natively (while i am a friend > of plugins, this is a case where one wants this built in, because "pitch > shifting" and "time stretching" is the same operation: it would be > senseless to first stretch within muse, then pitch somewhere else.) > > >, and even be midi note-driven to act as a sampling instrument. > > meeh, i think now we reach a point where we should better use a plugin. > we indeed can write a MESS (or better DSSI or even LV2 :)?) plugin which > acts as a soft synth, not using dump sampling rate conversion but real > pitch shifting. > > > Got a disk. Installing BSD now... > > yay :) > if you've problems, ask me or in ##freebsd on irc.freenode.net; they're > really competent and helpful. Arghhh! I just wasted a crap-load of time with PC-BSD. KDevelop won't start and is too old, SoundBlaster card not loaded, Yet Another Dumbed-Down Package Manager which lists only apps and nothing else, etc... The amount of foul language around here significantly increased yesterday. I don't give up easily but I've no time for this right now. We'll see if I can turn it around... Tim. > > > > greetings > flo ------------------------------------------------------------------------------ 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
