Re: [Audacity-devel] CVS Clobber and OnDemand
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Michael C. <mc...@gm...> - 2008-07-21 16:46:21
|
On Sat, Jul 19, 2008 at 9:23 PM, Martyn Shaw <mar...@go...> wrote: > Hi Michael! > > Sorry about the length of this (I thought Gale's post was long!), I've > been reviewing the wiki pages. > > Some comments on Gale's ideas below, but first a few comments of my own: > > I created a random track 1hr2min long, duplicated it so I had 4 > tracks, set 'Use custom mix' in the Import / Export prefs and saved it > as a 4 channel wav. This is my test file. > > When I open this file and click around, the 'loading' changes position > (a little sluggishly, perhaps). If I select part of the first track > and delete it, the 'loading' continues but somewhat randomly. > Deleting random bits causes the 'loading' to occur at different points > in different tracks, which is somewhat disconcerting. I think the > different tracks should stay in sync, from a users perspective. They > don't really know what's going on here and are likely to sit there > watching (maybe frustrated), rather than get on with stuff. I'm > guessing, but in this scenario each track is happening on a different > thread? They need to be synchronised when there is a new 'start' point. Yes, deleting clips throws the algorithm off. I'll have to fix this. > But this isn't really 'loading' is it, it's just the computation of > the summary data, yes? That may not be the way users view it. Any > ideas on how we make the track look like it's usable? I've thought about this a bit, and I wonder if it makes sense to put a dummy grayed-out waveform that is so simple that it is obviously not the real rms data. Something like a sinusoidal pattern. It will be "eaten up" by the OD loading of the real RMS data so it may be apparent enough that it just a temporary display, and the "waveforminess" of the sinusoid may suggest people can play over it. If it was animated to move like an oscilloscope that might make it more obvious that it was temporary, but that might be overkill on performance. if we overlay the "Loading Image...Click to.." (did we decide on that yet?) it would also help. > > If I split a track (Ctrl+I) and move it then click in it, I do not get > 'loading' from there. Same problem to above, I think. That's probably related to my last change when I made Tasks to WaveTracks a one to N relationship. It needs to be fixed for sure. > So a number of things to address about where 'loading' appears to be > happening. I think it should switch to the last 'click' time on all > visible clips, including one that have been time-shifted (more on this > below)... > > Gale Andrews wrote: >> | From "Michael Chinen" <mc...@gm...> >> | Thu, 17 Jul 2008 16:10:55 -0400 >> | Subject: [Audacity-devel] CVS Clobber and OnDemand >>> On Wed, Jul 16, 2008 at 8:40 PM, Martyn Shaw >>> <mar...@go...> wrote: >>>> I found it a bit odd that it loads 'backwards' once it has finished >>>> going 'forwards', but maybe that was a deliberate decision. >>> Yeah, I'm still unsure about this myself. It was a side effect of the >>> implementation, but it makes some sense - the user probably wants to >>> know more about the area he/she clicked on, and if it loads backwards >>> after it's finished everything past the click-point, it will be >>> loading the closest blocks to the clicks. But if a wrap-around or a >>> more clever (perhaps dithered) scheme seems more intuitive I'd love >>> input. >> >> My 2p is that backwards loading is sufficiently counter-intuitive that >> perhaps we shouldn't do it. Maybe it could forward load from a >> point to left of the click, then complete forward loading elsewhere? > > I prefer what we have, for the reason Michael said, it will be loading > the closest blocks to the clicks (but see below re pre/post roll). > >> I noticed that once you click further down the track and it starts to >> load from that click point, the loading from zero that originally >> started seems to stop altogether. Similarly if you click another point >> to right, that click stops loading elsewhere. I'm not sure that's a good >> idea - people may choose a few points down the track to load thinking >> this will get those points "started" when they want to work on the early >> part of the track. > > That would just slow the overall loading down, and give the disk a > bigger workout. It the users focus has changed then so be it. I > guess that a 'where I was list' could be created to continue loading > at the last place of interest, once the current place had been > exhausted; currently the place to resume is a little vague. > >> If you load a second track, that does not stop loading >> the first one, that seems correct behaviour to me. Is there a limit if >> people clicked in ten places (or imported ten tracks at once) to how >> many loads can be going on simultaneously? > >> I think you need to consider behaviour in regions. If you select a >> region down the track, might it be more useful if loading is confined >> to that region then loads from the left as if there had not been a click? > > Selected regions should be obeyed. Then not necessarily to the left > (see above 'where I was list'). Another option would be to add a few > seconds of backwards-loaded pre-roll and forward-loaded post-roll. > >> Also if you select a region from right to left, you don't get that >> region at all because it loads from the right edge of the selection. > > This is a good point. 'Loading' should happen from the LH edge of the > selected region, not the RH edge. (Then post and pre roll, then > 'where I was list'.) Current non-observance of the mouseUp needs to > be fixed in this case. That's true. I didn't realize this was happening, Will fix. Michael |