Re: [Audacity-devel] Linking changes!

[Al D. <bus...@gm...>]

On Wednesday 17 February 2010 15:19:02 James Crook wrote:
> Wow!
> 
> Just tried this out, and it looks good.
> 
> I think it is going to need feedback and tweaking of details from
>  actual use.  I know you hoped to avoid that by choice of a clear
>  definition of what should happen, but that is just how it is with
>  new GUI ideas.  At least it should require much less iteration
>  than starting from a less well thought out starting point would.
> 

For the most part the behavior is similar to what we had before. The 
major changes are interface-related -- user interface and programming 
interface (it should be easier to write correct code). We're starting 
from something that's been discussed a lot, but it will definitely need 
feedback and refinement.

> 
> - In linking mode generate may or may not move audio - it depends
>  on the size difference between the selection and the resulting
>  Audio.  That looks correct to me, but I can see some users being
>  puzzled at audio moving when they are generating audio at the end
>  of an existing track and silence gets inserted in the track above.

Hopefully users don't feel the need to select audio and generate a 
different length of audio in there very often. It's a major test case, 
for sure... and I don't know a better way to solve it.

>   Possibly a refinement is that the synchro selection is empty if
>  no audio would be moved in the normally selected tracks, i.e. when
>  making changes at the right end of tracks.  Not sure about this. 
>  What do you think?

That's interesting and I'd never thought of it. When inserting at the 
end of a track there's no pressing synchronization issue. If the 
"rules of linking" are written the right way that fits in. I'm on the 
fence right now, I'll keep thinking about it.

> - I was surprised that a change speed (slower) changed speed in the
> synchro tracks too, rather than adding silence - though I can see
>  the sense in it because we don't have that option when changing
>  speed (faster). 

I thought about this one a bit and it's one of a handful of things I 
changed from old linking behavior -- before when changing speed faster 
we'd lop off the end of audio in linked tracks, which kind of sucks 
(that is still what happens when you generate a shorter amount of 
audio into the selection). The main reason I chose this way is that it 
keeps everything within the selection synchronized. I'm not sure if 
that's the best way.

There are a number of possibilities with the pitch/tempo changing 
effects. The simplest thing you could do is track->SyncAdjust() 
(similar to what happens with generators) and the fanciest is probably 
applying the tempo changes without the pitch changes (it makes sense 
on some level but it seems like the kind of thing where some user 
would ask WTF was going on and I'd explain it, and then I'd pull on my 
suspenders* and fiddle with my pocket protector* and make some kind of 
geeky noise* as if to say, "Well, aren't I clever," and then he'd 
break my face on his fist).

The normal track->SyncAdjust() gives the user the most power -- users 
can always select all the tracks in the group if they want the actual 
effect to apply everywhere. Maybe that's the way to go.

 * I don't own suspenders or a pocket protector, but I can make a wide 
array of geeky noises; Audacity is a wonderful tool for recording 
them.

>  - A minor tweak to the chain-link background is to
>  start the image not at zero but at     internal position =
>  (xPosition mod bitmap-width).  At the moment extending a selection
>  left the chain links move, extending it right they don't.
> 

That's probably what it should be. I just got lazy writing the 
function (you wouldn't believe how much time it took me to make that 
chain link tile graphic... someone competent with GIMP could probably 
have made something better in 15 seconds).

> 
> Anyway, after a little getting used to it is very usable.  I like
>  this.
> 

Thanks for taking a look.

 - Al


> 
> --James.
> 
> On 17/02/2010 18:08, Al Dimond wrote:
> > I've made a number of changes in the last couple days to
> > implement the new linking scheme (same as the old linking scheme
> > but should be easier to program around).
> >
> > 1. You shouldn't see any changes unless you're building with
> > EXPERIMENTAL_LINKING enabled in src/Experimental.h. If you do let
> > me know or fix it if you feel like it.
> >
> > 2. If you want to try it enable EXPERIMENTAL_LINKING. Everything
> > I've tested so far works, but I'm sure I don't have everything.
> > If there are performance issues with selection let me know -- I
> > don't have any slow computers to test with here (sadly).
> >
> > 3. I'll document the new programming style for linking on the
> > Wiki soon.
> >
> > 4. Truncate Silence doesn't yet work with linking, but it doesn't
> > work with multiple clips yet either. That's my next order of
> > business.
> >
> >   - Al
> 
> -------------------------------------------------------------------
> ----------- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>