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? > > 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. > 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? > [...] 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) > > 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. > 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). 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. > > 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. > 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. greetings flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
