Re: [Audacity-devel] Repeat effect
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Martyn S. <mar...@go...> - 2007-08-19 00:26:22
|
Hi 'Repeat' now Just copies the selection over and over, including the envelope. Keeps it as a clip if a clip is repeated, or not if not. Does not try to do anything clever to save time/space. Selects just the new bit. I have a problem that I have been trying to solve for days and would appreciate some help (see next post). Martyn Martyn Shaw wrote: > Richard > > OK, so here's a plan: > > Always 'repeat' the envelopes. > Use the WaveTrack:: functionality. > Always do the same thing, irrespective of the number of repeat and their > length. > Allow a seperate clip per repeat, or not, depending on the simple logic > of 'if the bit to repeat was Split out'. > Post 1.4.0 is post 1.4.0, let's get it out! > > So what should be selected once the repeat is done? All the repeats or > the repeats and the original? > > I'm (slowly) getting there on this basis. > > TTFN > Martyn > > Richard Ash (audacity-help) wrote: >> Martyn Shaw wrote: >>> Hi >>> >>> There has been a couple of mentions of the Repeat effect on this list >>> recently, and I have had a look into it. >>> >>> I wrote the very long email (below) and then realised that maybe nobody >>> would follow it, so I've copied the conclusions here: >>> ================================================ >>> So what should it do? >>> >>> The current behaviour is inconsistent; it does different things >>> depending on the amount that you select. >>> >>> The logic of saving disk space seems redundant with the current cost of >>> disk space. >>> >>> Envelopes are ignored (I don't see why). >>> >>> Should it create a clip per repeat and a clip of the current selection >>> or not? (It does at the moment, see below.) >>> >>> I think if it were me trying to fix it (and I'm not saying I will, given >>> that I'm going away for the weekend and there's still a problem with the >>> EQ) I would dump the 'saving disk space' thing an use the higher level >>> functions in WaveTrack and WaveClip, but I have not thought that >>> through. >> >> I agree that the current behaviour is inconsistent and a pain. In the >> long >> term I (and a good many people using samples) would like there to be a >> way >> to repeat a chunk of audio in a way that mean modifications to the >> original chunk were reflected in the repeats. This is well post 1.4.0. >> >> I agree disk space is not a big issue, however I don't quite see why we >> have to use any at all - surely we just up the ref count on the "source" >> files as we use them, with the appropriate project file to say where to >> put them and how much clipping to apply. This is an under-the-bonnet >> issue >> right now which is separate from the interface issue. >> >> So in the sort term, we want some sort of logic for the interface when >> you >> select part of an existing clip, and hit repeat. First off I think it >> should never depend on how many repeats you ask for or how long the >> selection is. >> >> I think it would be nice to have an option in the repeat dialogue for >> "each repeat in it's own clip" or "all repeats in one clip". Both >> behaviours are potentially useful, depending on what you are doing. You >> can merge the clips back up, so if we don't have an option, we should >> hard-wire it to generate one clip per repeat, as you can always select >> the >> lot and do Edit > Join to get them all as one clip if you want that. >> >> The other question is what to do to the source clip. I think the >> answer is >> nothing (even if under the bonnet that means doing something and then >> undoing it), because if you want to split the selection to a clip, then >> you can use Edit > Split. >> >> As regards envelopes, I think they should be repeated with the clips, >> given that envelopes are clip-based (as per my previous email - if they >> were track-based, then they shouldn't be). This allows you to make your >> clip fade in / out with the envelopes, then repeat it and have it sound >> right. >> >> Richard >> >>> ================================================= >>> >>> >>> James C. pointed out to me some extra envelope control points created, >>> which I can't find. >>> >>> Gale pointed out some clip boundaries / Merge lines appearing (which >>> others may not always see, see below). From what I can see these are >>> genuine clip boundaries (move the other clips out of the way and you can >>> move them). >>> >>> (Incidentally, make sure you have 'Editing a clip can move other clips' >>> turned on in prefs->Interface->Behaviors if you want to follow me here.) >>> >>> Looking through the code I find that (see below for definitions of >>> 'thing'): >>> a) For 'short' selections that you ask to be repeated 'not many' times >>> you get no new clips created (no new clips and so no new Merge lines). >>> >>> b) For 'medium' length selections you get new clips but not as many as >>> the number of repeats (you get several repeats per clip). >>> >>> c) For 'long' selections you always get new clips created, one per >>> repeat. >>> >>> d) For 'short' selections that you ask to be repeated 'many' times, you >>> get a lot of repeats, then a clip boundary, then a lot of repeats etc. >>> This is the same as b) above. >>> >>> This is well documented in EffectRepeat::Process (that attempts to do >>> 'repeat' efficiently), and in WaveTrack::Paste, which tries to guess >>> what's going on. I quote: >>> >>> Repeat.cpp li 132-6: >>> // Create a track that contains 1 or more copies of the >>> // selection, cleverly arranged so that every BlockFile >>> // is within the minimum and maxmimum lengths of a normal >>> // BlockFile. That allows us to repeat the same sequence >>> // of identical BlockFiles, saving lots of disk space. >>> >>> and then when this gets copied in to the original track, using >>> WaveTrack::Paste; I have edited the following quote somewhat to >>> indicate the problem. >>> >>> WaveTrack.cpp li 437-453: >>> // Pasting is a bit complicated, because with the existence of multiclip >>> mode, >>> // we must guess the behaviour the user wants. >>> // >>> // Currently, two modes are implemented: >>> // >>> // - If a single clip should be pasted, and it should be pasted inside >>> another >>> //clip, no new clips are generated. The audio is simply inserted. >>> //This resembles the old (pre-multiclip support) behaviour. >>> >>> This is case a) above. No new clips get created when inserting the >>> temporary clip of copies. >>> >>> ... >>> // - If multiple clips should be pasted, these are always pasted as >>> single >>> //clips, and the current clip is splitted, when necessary. This may seem >>> //strange at first, but it probably is better than trying to auto-merge >>> //anything. The user can still merge the clips by hand (which should be >>> //a simple command reachable by a hotkey or single mouse click). >>> >>> This is cases b), c) and d) above. >>> >>> >>> In all cases envelopes within the selection are destroyed and not copied >>> to any repeats. >>> In no case where you get clips created are envelopes preserved within >>> the new region. >>> In a) the original envelope points are preserved if they are outside the >>> selection. >>> >>> So what should it do? >>> >>> The current behaviour is inconsistent; it does different things >>> depending on the amount that you ask to be repeated. >>> >>> The logic of saving disk space seems redundant with the current cost of >>> disk space. >>> >>> Envelopes are ignored (I don't see why). >>> >>> Should it create a clip per repeat and a clip of the current selection >>> or not? >>> >>> In my tests on Win XP at least: >>> 'short' = 0.5s >>> 'not many' = 3 >>> 'medium' = 2s >>> 'long' = 5s >>> 'many' = 10 >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Audacity-devel mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > |