Hi Mark
Nice one! I've been playing with it and functionally it's 'looking'
good! But 'looks' aren't everything. More below...
Mark D wrote:
> First, the list of changes from the wiki:
>
> * Added support for Change Speed.
> o Slowing down a section in a wave track adds silence to
> linked wave tracks.
> o Speeding up a section adds silence to that wave track.
> o Labels shift accordingly.
Isn't sample accurate, see below..
> * Added support for Generate functions. Chirp, DTMF, Noise, Tone and
> Silence all behave as Pastes.
Seem to insert and move labels with sample accuracy.
> * Fixed linking button not toggling states (Push down/pop-up).
Good. But the 'link' on the button could be better visually I think.
First time I saw it I thought it was a broken image. Any
pixel-pusher out there want to suggest a better version?
Also, status of menu item and button are not consistent (press one,
the other doesn't change). Needs some of that 'rebuild menus'
'rebuild toolbar' stuff?
> * Turned linking on by default.
> * Renamed menu item from "Link Wave and Label Tracks" to "Link Audio
> and Label Tracks".
> * Fixed bug related to cuts/deletes from label tracks. Selecting
> only a region in a label track and deleting it will delete that
> region in linked wave tracks. Selecting a label track in addition
> to a wave track is now the same as selecting only the wave track.
> If linking is off, the previous behaviour is used.
I don't remember the previous behaviour but... with linking off,
selecting a region within label X and pressing delete is now causing
other labels to the right to move left but the end of label X is
staying in the same place - I think this needs fixing (should be easy).
> * Fixed Cut behaviour when selecting multiple tracks. It previously
> copied one track, then ran the group clear, shifting the track.
> The rest of the copy calls would be copying the wrong selection.
> OnCut() no longer calls the wave track's cut functions (which call
> copy->clear), but instead calls the copy and clear functions
> directly.
I'm not sure I follow you, but Cut does not move the labels; is this
by design?
> The way I handle Change Speed may not be done. I was talking to Martyn,
> and he said that the length of the new track has an extra 10 samples at
> the end that may or may not be used.
'may or may not' is crucial here...
> I'm by no means an expert on
> audio/signals so I don't really understand the nuts and bolts of the
> algorithm. So is the usage pattern of those samples the same for all
> tracks? Like, if I drag a selection over 10 tracks, and run Change Speed
> on them, will they all either use the extra 10 samples, or all use no
> extra samples, but no mixing and matching (five use it and five don't)?
> Also, isn't 10 samples a matter of microseconds with regular sampling rates?
I think it will be consistent across all tracks (assuming they have
the same sample rate).
I like to see all these things sample-accurate (which you seem to have
achieved with the bits above). Here it isn't though. Here is a quick
test case:
Start Audacity
Generate tone 10000Hz, 1s
Skip to end
Generate silence 1s
Skip to end
Generate tone 10000Hz, 1s
Select the first tone and label 'one' (set the Selection Toolbar mode
to 'hh:mm:ss + samples' and make sure you have exactly (to the sample)
the first second selected)
Select the second tone and label 'two' (be exact again)
Click the 'one' label to select exactly the first second
ChangeSpeed to -80 (about 5 times as long)
(EffectChangeSpeed::ProcessOne li292 reports newLength to be
5.0001360544217688s = 5s + 6 samples)
Now zoom in repeatedly to the bit around the start of label 'two'
until you can see the samples.
If you see the same as me, the label and the start of the second tone
are off by 6 samples, which isn't good. Note that newLength in
ProcessOne had it right, and that is what I suggested you use. It
seems that the extra 10 samples catered for are sometimes used and
sometimes not, I have not looked into why that is and I don't think
you should either. I think you should use what the effect is
reporting (whatever the effect is), otherwise you will have to delve
into all of them (even new ones that haven't been invented yet).
but I was going to bed an hour ago...
> The problem with getting the length of the track after it's been
> adjusted and using that is that I do the shifting/inserting inside
> Process(), and not ProcessOne(), to avoid it being run multiple times.
> So, I'm anticipating the final size.
>
> Any opinions on changing OnCut()? It was a lot easier to do that than
> try to figure out some way to intercept the problematic cases after
> they've been called.
>
> Again, haven't built this on Windows/OS X.
Above comments based on an unmodified Win build.
> James: Thanks for the suggestion on simplifying the shift cases. I like
> it. =)
Yeh!
TTFN
Martyn
> Mark
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at
http://www.sourceforge.net/community/cca08>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Audacity-devel mailing list
>
Audacity-devel@...
>
https://lists.sourceforge.net/lists/listinfo/audacity-devel-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at
http://www.sourceforge.net/community/cca08_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel
