Editdudes, you're not my client; you're a fellow editor with a problem, and you're coming here asking me to spend my time to help you for free.  If you ask in a professional manner, I'll do the best I can to help you.  If you write posts like the one you wrote on the 21st, I'm going to ignore you and help somebody else, because to me, professionalism means dealing with colleagues respectfully.

good luck,
Carl

Carl, I didn't come here asking you to spend your time helping me for free. If that's what you think, I'm afraid you're totally missing the point here. As a fellow editor, I don't expect or demand anything at all from you.

I reported a bug that has already been reported on numerous occasions since september, but until now seemingly ignored by Avid. Posting the bug report here is an excellent way to inform other users of the issue, possibly shed some light on the problem and with a little luck get some response from Avid.

My criticism wasn't aimed at you or other moderators not on Avid's payroll, and I have already written a public apology to anyone who felt offended by the way I expressed myself. If that isn't enough, then what is? Please read the whole thread again if you missed it the first time.

When a moderator in error moves a detailed bug report to the feature request section, won't move the thread back to the correct section and can't even admit the mistake, then we have a problem. Not with the forum itself, but with the way Avid both sets the rules and appoints the moderators, and at the same time won't accept responsibility for the way these forums are operated. Moderation on these forums is a bit whimsical and inconsistent, and there's definitely room for improvement.

The problem with Avid Support (Not DS Support) is that bug reports are still handled in a less than satisfactory manner. No feedback is given, months (or even years) pass by and you have no idea whatsoever if the bug report ended up in the trash or if Avid has acknowledged the problem and is working on a solution.

There is no easy way to get information from Avid on the status of current bugs, but this may change in the future if Avid recognizes the true potential of these forums and acknowledges the fact that many users actually come here because they don't feel that the information they get from their dealers or support representatives regarding bugs and other issues is adequate enough.

As long as Avid doesn't offer an official status report for reported bugs, paying customers will (and should) post their criticism and opinions on the matter on these forums.

It seems that the reported bug has been escalated and dealt with now, and this is indeed good news. I can't help wondering if this thread improved the speed of processing this issue or not...  :-)

BLKDOG wrote: Evidenced by the crippling AMA bug that was reported here last week and fixed with a patch within seven days.

Wasn't the AMA bug reported in march?

Respectfully (no kidding)

BLKDOG on 7-23-2009:

Just checked on this bug and it had been reported through proper channels and is fixed. It is due to be rolled into an upcoming release.

Hi BLKDOG,

Any update on which version of Symphony will include the bugfix for SubCap?

I've just installed v3.5.9 and the anchor problem still exists.

Seems overdue.

Regards,

Ian

Bump!

BLKDOG, MARIANNA, ...anybody?

EyeBee: earlier today:

Any update on which version of Symphony will include the bugfix for SubCap?

I've just installed v3.5.9 and the anchor problem still exists.

Seems overdue.

Maybe I'm being blanked because of the Sub**** Tool header, above. I actually think it's quite a cool function, designed to improve the Avid experience, and add value for our Avid-centric clients. Personally, I can't use it without the obvious bug fix that has been identified and, apparently, sorted. Need to to know, however, where it's going, due to client pressure.

Regards,

Ian

bump.

Any news on when this fix will be included in MC?

As you know, Avid never releases information on when bug fixes will be included in releases. They are a publicly held company and, as such, are subject to SEC rules and covenants.

However, I can tell you that it is on the list. It's not high up, it's about in the middle of the pack. I can also tell you that the bugs above it are definite show stoppers . I can't see any of the bugs above it as candidates to slip their place for this one.

I'm confident that it will be fixed as soon as it's possible to get to it.

Ian, I want to make sure we're talking about the same issue.

Do you mean the fact that, regardless of the anchorpoint choice (Left, center or right) that the cursor alsway stays justified left?

That's the bug to which I am referring and, to me and my work, hardly a reason to not use the feature.

Or is there something more serious I am missing here?

Hi BLKDOG

The 4.0.3 read me has a list of about 36 pages with limitations and known issues. Would you mind sharing with the rest of us which show stopping bugs you're referring to?

Best regards

Nope. Can't do it. I want to be as clear and as open with you as I possible can but, discussing Features and or Bugs in relation to when they Will be included in future releases is completely verboten.

If you take a look at the limitations in the read me though, you can get a pretty good indication of what code gets priority.

So, you ask when this particular issue will be fixed and all I can say is it will be as soon as it can possibly be. It's not ranked a highest priority but neither is it the lowest.

Ok, I can make an educated guess as to what's on your short list.

Unfortunately the list of issues and bugs is so long that we probably won't see any Symphony specific feature updates within the next couple of years. Symphony doesn't get the attention it needs these days, but perhaps that's intentional?

Hi BLKDOG,

I'm posting this back on the original SubCap thread, since I am assuming that you have locked my follow up thread.

It's disappointing, to say the least, that you seem to have missed my many questions (several of them asking you personally, as the quoted moderator, to respond) regarding this bug with SubCap.

ref: http://community.avid.com/forums/t/76911.aspx

It seems to me that only the recent (11-12-2009) interjection by 'editdudes' has illicited your intervention at this stage.

Let me say right now that I have no wish to take part in, or be part of the recent firefight ....

I see that that you have just posted today (11-12-2009) a reply to my post on (10-23-2009)

BLKDOG:

Do you mean the fact that, regardless of the anchorpoint choice (Left, center or right) that the cursor alsway stays justified left

OK you've caught me at home on a Thursday night with my slippers on, but I don't think your description of the bug describes the symptoms in full.

The following is quoted with the proviso that I'm not in front of my Symphony at the  moment - I'll check in the morning.

You seem to be of the of the opinion that the anchor point bug is solely concerned with the fact that the anchor point indicator does not reflect the status of the 'left-centre-right' status of the text editing. This is true, but from memory I think the major issue is that the subtitles generated don't themselves reflect the request (for instance) to be centre justified.

My original query was posted because when I tried to use the Subcap tool and couldn't generate a set of centre justified subtitles, I was baffled - without that facility it was of no use to me. It's as simple as that. Not just that the anchor point indicator is bugged ...   I then came across this thread, and then instead of ducking for cover, I tentatively bumped it.

You volunteered the fact (23rd July) that the bug had been fixed, to be rolled out in a future release - I was simply querying whether it was reasonable to assume that this should have been fixed in Symphony 3.5.9 (which was released on 19th October - after v4.x - the next generation of Avid).

I'm sorry that you have taken offence to my requests - I'm actually quite shocked.

I'll check the status of SubCap tomorrow on v3.5.9, but your post has me concerned that the bug may not have been identified correctly.

Regards,

Ian

I'm sorry EyeBee, I don't mean to be dismissive but I honestly didn't know that I was responding to you. My responses were to editdude with whom I've corresponded on the issue.

So, please don't think that I was offended in any way cause that is just not the case. I also have not seen any list of questions from you. I am not often able to read long threads like this one in their entirety so please forgive me if I missed a post from you. If you need me to respond directly to questions, you are always welcome to email me.

As for the bug described, I do understand the problem to be that the text itself can be justified within the text box but the text box itself cannot be easily justified. the justification parameters in the Effects Mode Editor are only for within the text box itself.

The reason for this is simple, that feature is just not a part of SubCap at this time. The only way the positioning of the text box works currently is to drag the anchor point to a position and to use the grid in the TT to place it in the center.

Not the way any of us wants to work but, in development terms, this is not a bug, it's a feature request. We (including me) consider it a bug because it needs to work differently but, in product management language it is as designed and needs to be changed on a feature level. This request has been assigned a bug number anyway and is one of the highest feature requests in the list. So, as I said, the feature to justify the whole text box WILL be added soon. If it doesn't get added (as it hasn't in the last two versions, it's because more pressing (actual) defects have moved it down the line.

The workaround, until then, is to create a text box that stretches from the edge of the grid on the left all the way to the right and then justify the text appropriately. I've done many shows for broadcast this way and it works well for us. Hopefully it may be of help to you. If you want  the box to be constrained to the width of the line of text, it becomes a bit tougher to hand justify the row but certainly do-able.

Please feel free to email any questions you may have directly to me if I happen to miss a post. I'll do all I can to get the answers for you.

Hi BLKDOG, thanks for your reply.

OK ... back in front of the old girl now.

I have now reminded myself of the circumstances which caused my anguish.

The left/centre/right justification of text works within the box area.

The anchor point of the box is rigidly fixed to the left hand box edge.

So ... if you want to centre the box and the text you are forced to leave the box at a 'fixed width' - say edge to edge of your safe area. This is ugly. The box menu 'each row as wide as needed' - which is the obvious one to use - causes the box, and text, to change in length, justified to the immovable left hand anchor point.

This, in my opinion, is not functionally appropriate, and should be pursued as a 'feature request' with all speed.

As you say, the final result can be achieved manually, but at a huge time cost. Quite an omission.

Thanks for your interest.

Kind regards,

Ian

BLKBOG,

I vote fully with EyeBee.  Bug or feature request I will not argue.  Even though I would like to.  

But, my clients have need of the centered option described.  The workaround is only slighty better than doing this manually.  Which for long form makes it very expensive.

So if there is any weight in more voices, here is mine.

EDIT:  While this problem may not seem like a show stopper in the grand scheme of things, I submit that it is for this one tool.  It basically makes doing the "BBC Style" (as my clients have called it) of open captions not as cost effective as other, less attractive (to my clients that is) styles.  This tool was highly advertised when it came out.  For some customers it is a big selling point.  It seems now to have limited use.  Just trying to give a full explaination.

Thanks,

Jef