Losing sync after ALT-F to add effects

[ScorpioProd]

I don't blame John, I probably last "officially" reported it before his time.

Oh yeah, I remember it biting me the first time back then like what happened to BBeanan. It isn't really that unusual to be bit by things in new software. I remember how bad it was when VT[2] came out and I believed DV worked, turned out it didn't. It was dropping frames in the decoder every so often. That one burned me real bad. And hey, Sony hasn't had much luck with Vegas Pro 9 lately, either. The 9.0 version had some bad bugs, and the 9.0a version fixed those and added some frankly more fatal ones for me. I'm starting to ponder Final Cut Pro 7! (EDIUS is rather in limbo with Thompson selling Grass Valley, so no point in looking there.)

As for it being a "new problem", I meant that more in the sense that VT-EDIT/SpeedEDIT isn't "new" software, so it just popping up now wasn't likely, as in it's always been there. If the software just came out, as in my examples noted above, it would be much easier to forgive the bug.

And yes, people treating bugs as not being real is always a problem, in all products.

Though it won't help people currently, the announced subproject capabilities in SpeedEDIT 2.0 should prevent this problem, by allowing multiple audio clips and video to be grouped in a subproject before doing one's editing. That should prevent the problem, no matter what the cause.

Subprojects are the method of grouping coming to SpeedEDIT, versus more traditional grouping commands.

 

[Quiet1onTheSet]

Though it won't help people currently, the announced subproject capabilities in SpeedEDIT 2.0 should prevent this problem, by allowing multiple audio clips and video to be grouped in a subproject before doing one's editing. That should prevent the problem, no matter what the cause.

Permit me to disagree with the core of that sentiment, Eugene, Buddy, inasmuchas the idea of invoking a "Subproject" for example, on, say, 3 clips, in order to avoid "clip drift" after global FADES were inserted, would constitute a shameless workaround. As was intimated, coded properly, ALT+F shouldn't have caused this phenomenon at the first.

I grinned in gleeful anticipation, when you conveyed something along the lines of wishing the best for whomever might think this can be resolved without a code rewrite to support traditional grouping. Well, apparently, good-riddance, John Perkins soundly pulled it off!

Methinks the objection cited above is supported by

• the absence of the problem on other NLEs
• yesterday's investigation, resulting in an official judgment that indeed, we've been dealing with a bug all along, and
• a causal discovery, for which was found, a fix, which hopefully will be forthcoming at least in the form of an update or patch for current NewTek editing platforms (TriCaster series, SpeedEDIT-VT and SpeedEDIT standalone) and not just the SpeedEDIT 2.0 upgrade (let us pray...)

My personal preference, admittedly, is still for a 2.8 release (with the ALT+F improvement jaunt included, of course).
:thumbsup:

Now, with respect to some problematic issues with Sony's latest Vegas Pro 9 build, as you cite above, Eugene, I'm *stunned* to hear you've been so yanked! What on earth went wrong?

And how -- unfortunate, to learn of the relatively dim prognostication in the minds of some, for the continued development of Grass Valley EDIUS!

Goodness. Could NewTek SpeedEDIT 2.0 possibly enjoy a bit more generous slice of the market, before long? 'Guess we'll just have to wait and see...

Q1

 

[ScorpioProd]

Permit me to disagree with the core of that sentiment, Eugene, Buddy, inasmuchas the idea of invoking a "Subproject" for example, on, say, 3 clips, in order to avoid "clip drift" after global FADES were inserted, would constitute a shameless workaround. As was intimated, coded properly, ALT+F shouldn't have caused this phenomenon at the first.

I disagree. It's not a workaround, shameless or otherwise, if that is the workflow that Newtek designs SE to use in that situation.

IF I am correct that the problem is the lack of grouping capability in SE, then the only way to fix it is with a grouping capability, no other fixes would work. And the only announced grouping coming in SE 2.0 is via subprojects.

When I hit the problem in the past, I would certainly have been happy to have a workflow where I could have grouped everything in a super subproject with full control tree capabilities and a conformed audio waveform.

There is no way that I can imagine SE reading the user's mind to know if a bunch of clips should be affected together or not. Imagine the problems if there is a "fix" that suddenly starts affecting things the user didn't intend to be affected.

I grinned in gleeful anticipation, when you conveyed something along the lines of wishing the best for whomever might think this can be resolved without a code rewrite to support traditional grouping. Well, apparently, good-riddance, John Perkins soundly pulled it off!

As I said before, I think he fixed a different problem.

Methinks the objection cited above is supported by

• the absence of the problem on other NLEs
• yesterday's investigation, resulting in an official judgment that indeed, we've been dealing with a bug all along, and
• a causal discovery, for which was found, a fix, which hopefully will be forthcoming at least in the form of an update or patch for current NewTek editing platforms (TriCaster series, SpeedEDIT-VT and SpeedEDIT standalone) and not just the SpeedEDIT 2.0 upgrade (let us pray...)

And that's because:

• other NLEs have grouping so they don't have this problem.
• the bug found by John doesn't match what was described by the OP.
• I can't imagine any patch being released versus a true upgrade.

Now, with respect to some problematic issues with Sony's latest Vegas Pro 9 build, as you cite above, Eugene, I'm *stunned* to hear you've been so yanked! What on earth went wrong?

The same thing that goes wrong with any software. No matter how good or numerous beta testers are, stuff will always slip through and screw up early versions of major upgrades to any software. No one edits the same exact way as anyone else.

And how -- unfortunate, to learn of the relatively dim prognostication in the minds of some, for the continued development of Grass Valley EDIUS!

That's what I heard from some others, and I agree. It would be a huge risk to go to EDIUS now with its future uncertain. Same with Avid, they're bleeding money currently.

Goodness. Could NewTek SpeedEDIT 2.0 possibly enjoy a bit more generous slice of the market, before long? 'Guess we'll just have to wait and see...Q1

With John in charge, good things could happen.

 

[Quiet1onTheSet]

Beware the "Group Think" Pathology!

I disagree. It's not a workaround, shameless or otherwise, if that is the workflow that Newtek designs SE to use in that situation.

Goodness! I'd hate to think NewTek engineers developed the SubProject concept, originally, to avoid Alt+F Clip drift per se, though, I must concede, it does indeed turn out to be a handy-dandy if not a bit compromising, temporal fix (read: as a stop-gap approach until, in the fullness of time, John Perkin's newly tested method would come to the light).

In my admitted ignorance, I'd like to imagine that Subprojects were originally developed to address a higher-order need for some means of locking clips with respect to one another, for ease of managing clips in large projects, perhaps; and it just happily filled the bill, as an Alt+F A/V Sync bug, er, "workaround".

IF I am correct that the problem is the lack of grouping capability in SE, then the only way to fix it is with a grouping capability

Why so resistant to the idea that John fixed the same bug, mate? Your having surmised over the years...

"... if clips could be grouped, the problem would be solved.

...isn't a major fallacy, but that perspective certainly hasn't helped the Alt+F Improvement Cause.

But what's troubling is that your presupposition may have held you hostage to the degree that even now that a true fix is apparently in the pipeline (terrific outcome for end-users, once the Group-Think was challenged), you don't appear as happy and delighted as I imagined you'd be.
:bangwall:

See what I mean?

Don't get me wrong: your passion for grouping isn't a bad thing at all (it's a great thing when kept in balance). It's not a good thing to let it get in the way of perceiving possibilities for our beloved software becoming even better, even with design limitations you've valiantly championed against for almost a decade.

When I hit the problem in the past, I would certainly have been happy to have a workflow where I could have grouped everything in a super subproject with full control tree capabilities and a conformed audio waveform.

It seems evident to me at least, that your passion for that capability over the years, may well have skewed your ability to objectively imagine that there are potential fixes for SpeedEDIT that don't rely on the "Need Grouping" presupposition you're so prone to cast yourself upon, when discussing issues with the NewTek way of editing.

There is no way that I can imagine SE reading the user's mind to know if a bunch of clips should be affected together or not.

Absolutely, and no one represented in this thread could possibly have been imagining that.

But you bring that up, because of how you've been approaching this Alt+F debacle over the years, which has been leading you down the wrong path, relative to the possibility in your mind, of it ever getting fixed.

Imagine the problems if there is a "fix" that suddenly starts affecting things the user didn't intend to be affected.

Oh? Imagine if that was the overarching fear of software engineers, every step of the way in developing fixes for creative software: Why, the poor app would languish on the programming engineers' development platform for years!

As I said before, I think he fixed a different problem.

Ah, not so fast, Eugene.

• The original poster is is working within the now nascent, VT-EDIT (that's alluded to, in Post #35, in his mention of the last build of VT[4]).
  
• John P. is developing SpeedEDIT 2.0, and apparently fixed the very *kind* of issue Travisr is having, only within different software (who knows -- could it be SpeedEDIT 2.0 alpha?) instead.
  
  Sure, the outcomes for their respective sync problems in the case of an Alt+F action is different (remember too,
• Travisr is working within a Windows XP Pro environment, whereas
• John P. likely is working within a much, much newer OS.

Even so, their respective A/V sync issues are not unrelated, as best as any of us can tell (that would include yourself).

That said, let's happily assume the issue is far and away more "fixed" on the new platform, than it's ever been on any other -- the (possible) lack of traditional clip grouping in the build John P.'s working with, notwithstanding.


Was there not at least some modicum of dancing on your part, in the form of a seeming unwillingness to objectify the differences noted above, relative to the different outcomes?

• other NLEs have grouping so they don't have this problem.

Naw. That's not the determinant here! Since the days of VT-EDIT, had other NLEs provided their users, a single-action, multiple fade insert functionality throughout a project? (I don't *think* so!)

• the bug found by John doesn't match what was described by the OP.

So? Nor does John's host PC configuration; nor his VT Suite version; plus, as noted eariler, VT-Edit ain't SpeedEDIT-VT either.
hmy:

• I can't imagine any patch being released versus a true upgrade.

Not surprising, given how close we are to a Beta for SpeedEDIT 2.0 (not to mention your reluctance to imagining there could possibly be an Alt+F fix without grouping.


So, as it is, Vegas Pro 9 jacked you in some way. I'd surely like to think there's forthcoming a fix for that -- whatever it is; and that it won't take years for it to come about either.

But then, I could be wrong on that. After all, that kind of delay for a fix is something that goes awry with any given software.

With John in charge, good things could happen.

Indeed! And we all wish him well!
:agree:

 

[travisr]

I don't believe the bug that John fixed is the same bug I was seeing. I did my best to describe what I was seeing. It's nice to know that Scorpio recognized the problem from his experience in the past. Having two users share the same symptoms that can be reproduced seems to qualify it as a bug.

I've been able to state the problem. I've been able to state the conditions that cause the problem for me. I've been able to provide some details about my system. I've found someone else on here who could identify with the problem and who has experienced the same results. I appreciate the feedback from everyone, as I think this is a great community of support. But I'm not necessarily able to spend a lot of time thoroughly testing and filling reports. While I admit that would probably benefit me and others in the long run, I've got projects to edit and like many editors, when I find a quick fix, I will usually take that route in order to satisfy the client in a reasonable time frame. I feel like I've provided adequate information to help identify the problem and what is required to reproduce it. I was even able to determine the frame offset, and the fact that it is consistent.

Hopefully other people benefit from what I've learned, and maybe someone at Newtek will be able to wrap their head around the problem as well.

 

[ScorpioProd]

Travisr, you've provided lots of useful info, and John is on it now, you've certainly done your part, no worries.

But yeah, I definitely know the exact bug you're describing, I've always attributed it to not being able to group clips, but it certainly may be something SE could improve on even without true grouping. And like I said, I think I also know the bug that John found, which is an incrementally building error issue that's different.

Peter, no, subprojects do have a higher goal than getting around this bug, but I certainly think they are a useful and practical way around it, if there isn't a better one available. And note that I do mean the "super" subprojects coming in SE 2.0, I don't find the current ones adequate for this since there is no conformed audio waveform in them.

I'm not the least bit resistant to John fixing lots of bugs, but as Travisr and I have stated, what he described as fixed isn't the bug that was described. Of course, one less bug is always a good thing. :thumbsup:

Honestly, I would like SE 2.x to be great, but I wouldn't call it my "beloved" software at all. The days of my being passionate on NLE software are long gone. It's a tool, nothing more, nothing less. If it does what I need I'm happy, if it doesn't, I move on.

Oh? Imagine if that was the overarching fear of software engineers, every step of the way in developing fixes for creative software: Why, the poor app would languish on the programming engineers' development platform for years!

Hmmh... That could explain a lot, couldn't it... :hey:

Since the days of VT-EDIT, had other NLEs provided their users, a single-action, multiple fade insert functionality throughout a project? (I don't *think* so!)

If you don't think most NLEs can do that, I really encourage you to try some of the free demos out there. That function is not the least bit unique. Maybe at one time, but certainly not today. Can I do that just as easily in Vegas Pro 8? Sure I can.

Remember, when it was new, VT-EDIT had a lot of cutting edge features that other NLEs didn't have. Comparing SE to other NLEs today in the same way, well...

So, as it is, Vegas Pro 9 jacked you in some way. I'd surely like to think there's forthcoming a fix for that -- whatever it is; and that it won't take years for it to come about either.

Sony Creative Software does have a very good user bug reporting system. In fact, the main way I would say it is superior to Newtek's is that someone ALWAYS contacts you shortly after and follows up the bug with you, iteratively as needed. IOW, you KNOW what happens to the bug, all the way to the conclusion, versus throwing it in a black hole and hoping. That is how I see Newtek's automated system, it is of course different if one talks directly to John about it, but that's not what one would normally do.

Though just like Newtek, SCS won't typically issue a patch versus waiting to roll fixes into the next upgrade, that's pretty standard practice.

 

[Quiet1onTheSet]

Travisr, you've provided lots of useful info, and John is on it now, you've certainly done your part...[/quote]

Eugene's absolutely right on that, score, you've done more than admirably.

But yeah, I definitely know the exact bug you're describing, I've always attributed it to not being able to group clips, but it certainly may be something SE could improve on even without true grouping. And like I said, I think I also know the bug that John found, which is an incrementally building error issue that's different.

To be honest, I could wish NewTek still offered at least patches and codec updates for VT-EDIT in the app Travisr is using (VT[4]), since we too have that still sitting on one of our machines. But I suspect that won't happen, owing to NewTek's forward look toward newer systems.

Even with a Hyperthreaded 3.06 GHz single core, Intel P4 processor, I loved the VT[4]'s responsiveness in editing on that XP Pro machine.

I'm not the least bit resistant to John fixing lots of bugs

Duly noted, and as well, no one here has suggested otherwise.

... but as Travisr and I have stated, what he described as fixed isn't the bug that was described

Agreed: yet, there's certainly a relationship in how the two undesirable, divergent results are created, likely owing to the two very different OSes, VT versions, and Editing apps involved, but the bugs themselves are likely very much related. Yet, the suspected reasoning for the differing manifestations of the bug on two disparate apps and host systems have been subjected to an eerily strange de-emphasis (outside my observations) of course. But we agree that John's findings and actions for a fix is a beautiful thing:

...one less bug is always a good thing.

Hmmh... That could explain a lot, couldn't it... :hey:

I hadn't imagined that you're given to an occasional blatant tendency for isogesis: i.e., stripping one's statements out of their intended context, for gratuitous use, mate! Whoops. Looks like that's happened in the next paragraph \as well. But no worries...

...[Concerning global fade insert that VT-EDIT provided:] That function is not the least bit unique. Maybe at one time, but certainly not today.

Correct; That's precisely what I've intimated, in as much as my statement (which didn't make it into your quote) was clearly contrasting VT-Edit's global Fade Insert feature with that lack in other NLEs at the time.

Sony Creative Software does have a very good user bug reporting system. In fact, the main way I would say it is superior to NewTek's is that someone ALWAYS contacts you shortly after and follows up the bug with you, iteratively as needed.

IOW, you KNOW what happens to the bug, all the way to the conclusion, versus throwing it in a black hole and hoping. That is how I see NewTek's automated system, it is of course different if one talks directly to John about it, but that's not what one would normally do.

Salient points! Decent exchange with you too.

Q1

 

[ScorpioProd]

Agreed: there's certainly a difference, likely owing to the two very different OSes and VT Editing apps involved, but the bugs are likely very much related.

The suspected reasoning for the differing manifestations of the bug on two disparate apps and host systems have been subjected to an eerily strange de-emphasis (outside my observations) of course.

I certainly accept that you think they are, but I honestly don't.

Thought you'd run with that, only I hadn't imagined that you are given to isogesis: i.e., stripping one's statements out of their intended context, for gratuitous use, mate! Whoops. Looks like that happened below as well. But no worries...

Sure I am, just ask Steve.

Correct; That's precisely what I've intimated, in as much as my statement (which didn't make it into your quote) was clearly contrasting VT-Edit's global Fade Insert feature with that lack in other NLEs at the time.

Ah, OK. Though honestly, I don't know what other NLEs could do at the time, cause back then I was only interested and experienced with Newtek's.

I think SpeedEDIT 2.x has tons of potential, a lot of NLE companies and their products are hurting now, so if there was ever a time for it to strike, it would be now.

I just personally don't find that SE 1.5.5 compares that well to other current NLEs. If SpeedEDIT was out a few years before it was, it would have, but it wasn't. And as we all know, the development for it, as in actual upgrades that the user could get, in the last couple of years, simply didn't happen.

I hope that SpeedEDIT 2.x is a paradigm shift for the development of it.:thumbsup:

 

[John Perkins]

This will have fixed at least one instance, but if this doesn't fix the case you guys describe, please do help me to isolate the problem. Getting this random result out of the way should allow us to track down others more reliably.

Grouping shouldn't be needed to assure sync in most of the situations I've heard described. I don't believe that's what groups are for, that's asking for a crutch rather than a proper bugfix. If you can't depend on the basic tools, grouping doesn't help in the long run.

Multi-layered ripples where a section needs to act as a unit would be a good use for groups or subprojects. The editor just can't be made smart enough to understand this case without marking it as such in some way.

To some potentially large extent, subprojects can be a stand-in for groups, but I understand the need for both.

I'm all for grouping and I intend to get that in SE when we can, we just have other issues that need to be worked on to get SE up to speed (pun intended) at his point in time.

 

[Quiet1onTheSet]

SpeedEDIT-VT™ vs. VT-EDIT™ Plus Other Under-Rated Distinctives?

Multi-layered ripples where a section needs to act as a unit would be a good use for groups or subprojects. The editor just can't be made smart enough to understand this case without marking it as such in some way.

Of course, there's the frequent confusion of terms: that is, "grouping" verses "locking" of clips. Two different animals altogether, really.

OK. That reminds me: a couple years back, a feature request suggestion was made, for VT-EDIT™ that fathomed the idea of having the end-user select, then "ghost out" portions of the project which he/she wanted to create a single, unmovable group of clips.

Also, it was suggested that perhaps this proposed, VT-EDIT™ feature for isolating then locking down project portions (so they'd stay in place, relative to Project Time), could be engineered so as to yet allow the end-user to perform the OVERLAY function thereupon.



On another matter:

Grouping shouldn't be needed to assure sync in most of the situations I've heard described. I don't believe that's what groups are for, that's asking for a crutch rather than a proper bugfix. If you can't depend on the basic tools, grouping doesn't help in the long run.

Thanks very much. 'Appreciate your kind confirmation of my unrelenting suspicion, which has been a most difficult sell for a fellow non-programmer I've had the pleasure of discussing this with. It appears to me at least, that my friendly adversary sometimes takes a SpeedEDIT (or VT-EDIT) bug discussion in the wrong direction: as a seeming fruitless opportunity to pounce on the lack of clip grouping: a feature, which, needful as it is to have, wouldn't be the end-all/be-all solution to getting SpeedEDIT up to "speed".

I can see the default transition length having an impact if it is what I suspect, but that's pure speculation until I know how to fix it.

1. Now that some fog of speculation has been cleared out of the way, can you state for sure, whether or not the PREFERENCES setting for DEFAULT TRANSITION LENGTH could impact the outcome with ALT+F, in the current SpeedEDIT or in the older VT-EDIT apps?

This will have fixed at least one instance, but if this doesn't fix the case you guys describe, please do help me to isolate the problem. Getting this random result out of the way should allow us to track down others more reliably.

Oh, OK, JP. Now, assuming that you're now aware that the bug manifestation instance the original poster provided here, is one which exists on a platform that's different from the one your tests were performed on (i.e., Travisr is working on the following... )

• VT[4]'s VT-EDIT (read: this is *not* SpeedEDIT-VT, from which this forum derives its name)
• Windows XP Professional Note: While we're not informed, relative to this, but let's suspect he's using XP Pro 32-bit, rather than 64-bit.)

2. Are you now indicating that users of the older, yet capable, VT-EDIT™ platform could provide you useful information, that might facilitate an improvement in SpeedEDIT 2.0 and SpeedEDIT-VT down the road?

3. Care to further enlighten us on the matter of how our providing NewTek bug reports for VT-EDIT (predecessor to SpeedEDIT-VT) can give clues to how to improve SpeedEDIT 2.0 development?

Psssst! Within the construct of attempting to further aid his work in fully squashing the bug, with the help of users like Travisr, who've experienced the -15 Frame Offset on the very last audio clip, I now wish John Perkins could know..
a. What's the default TRANSITION LENGTH setting the enduser (e.g., Travisr) has set up in VT-EDIT PREFERENCES, when the " -15 Frame Offset on Last Audio Clip" bug manifests?
b. If using Windows XP PRO with VT-EDIT™, is that XP Pro 32-bit or 64-bit?
c. Which CPU does the VT[4] host machine reveal is in use, within START > SETTINGS > CONTROL PANEL > SYSTEM ?

Q1

 

[travisr]

As I mentioned before, my default transition length has been 1 second and also 1/2 second when I've had this problem occur. The same 15 frame offset occurred in both instances.

 

[Quiet1onTheSet]

As I mentioned before, my default transition length has been 1 second and also 1/2 second when I've had this problem occur. The same 15 frame offset occurred in both instances.

'Sorry I missed that, thanks.

Any additional info anyone can provide about the ALT+F bug, describing in detail,

• the specific details of the unexpected impact it has on your project -- i.e., what happens to audio (and/or) video clips in the project, after ALT+F is executed?, and also
• the condition required to duplicate said bug -- i.e., what pertinent SpeedEDIT-VT or VT-EDIT PREFERENCES do you have set up? -- and just as important:
• what is the makeup of your host PC environment -- i.e., please provide CPU make/model; The full name of your Windows OS version (also, 32 or 64-bit?)
• the description of VT version
  
  Note: SpeedEDIT-VT does not appear until VT[5].
  
  Travisr, thanks for everything.
  The existence of this thread you created, and the useful info you and others have provided NewTek just these few days has yielded fruitfulness in the way of a potentially tremendous benefit to the community. :thumbsup:
  
  p.s.: Anything NewTek might do, to tweak VT[4] ver. 4.6, build 6016, so as to provide patch(es) for
  
  • codec compatibility with VT[5] and TriCaster 2.5
  • streaming format compatibility with VT[5] and TriCaster 2.5
  • accuracy in the use of ToasterCG
  • precision in the use of the ALT+F command
  ...would be hugely appreciated, since we've found that, while integrated with even the latest NewTek tools, having the older VT-EDIT in one of the edit bays works great, as it's extremely responsive, even on single processor machines under XP Pro 32-bit.
  
  
  Q1

 

[Rich Deustachio]

Because of this bug, when I edit dance recitals I don't cut up the clips, I just sync them on top of each other and use a dissolve or a cut DVE to select the different camera shots. Then I will cut out the black out sections between the dances.

 

[travisr]

Because of this bug, when I edit dance recitals I don't cut up the clips, I just sync them on top of each other and use a dissolve or a cut DVE to select the different camera shots. Then I will cut out the black out sections between the dances.

Wow, that must take forever.

I like using Bobs multicam. For dance recitals, I can usually zip through the timeline at 2X speed and make my edits. Once I do, I add the dissolves, and then remove the dead spaces. Of course, it's so much nicer when the audio doesn't shift!

 

[Quiet1onTheSet]

Wow, that must take forever.

I like using Bobs multicam. For dance recitals, I can usually zip through the timeline at 2X speed and make my edits. Once I do, I add the dissolves, and then remove the dead spaces. Of course, it's so much nicer when the audio doesn't shift!

It so happens that we're about to install BobFX "Complete" for VT[5], then, look around for the patch for 5.2b.

Just wondering: When first installing Bob's plug-in software, must the user connect with him via Email, for validation, before he/she is able to put MultiCam to use? Oops! Serious thunderstorms in the area right now (logging off).

Thanks for any advice!

Q1

 

[Quiet1onTheSet]

Nascent? Oops! Had to correct that improper word usage...

Ah, not so fast, Eugene.

• The original poster is working within the now...

• ...sunsetting, VT-EDIT (that's alluded to, in Post #35, in his mention of the last build of VT[4]).

 

[WWaters]

Hello all,

Could anyone provide an update on this issue? I would like to add that I have experienced both the audio issues described by Travisr and the bug that John P. was describing.

If it would help I could add info to the bug report. Should I reference a report number?

 

[WWaters]

Working today and just found this same problem. I realize that this is a VT forum, however I believe the OP's issue is a SE bug not just on VT .
This also may be different since I am using 3 audio tracks grouped together in a Sub project. I have included screen shots so that everyone can see what's going on.

Please notice that the A/V lock is disabled on both vid clips.

This is what happens after pressing ALT + F to add transition between these two files. Keep in mind nothing but these 2 files are selected and the audio in the subproject is not highlighted. The Sub-project is moved over by 15 and all audio following is also ahead by 15 frames.

Here are the pertinent Prefs

I can get this to occur every time there is nothing ahead of the audio clip in question. Using ALT+F moves all audio that is not locked to a clip ahead on the timeline by 15 frames.

Machine specs are:
Macbook Pro Running Vista Ultimate under Bootcamp
Intel Core Duo 2.0 Ghz Processor
2.00 GB RAM
SE 1.5.5

Other possibly important factors
-The total project length is 1:18:47
-Other than the subproject audio grouping, there is a single audio track (A/V Lock is not ticked on any clip)

Again, I will copy this over to Fogbuzz if you all suggest it.

Thanks.

 

[SBowie]

Again, I will copy this over to Fogbuzz if you all suggest it.

Absolutely.

 

[WWaters]

Posted today to Fogbugz