@gary-rebholz

You have stolen my thunder. I was just about to write something.😅

Now, I'll make it relatively short. I think, all of you can see, the development team is at least as passionate as you are. Therefore nothing which was decided to do was decided upon without great thought and consideration.

For now we are comfortable with what we decided to do and we are proud what the developers accomplished in just under a year. We're aware of all the improvements you want us to implement in VEGAS Pro. It will be a ton of work and change won't happen over night but the driving force behind this will be your requests.

So, please report any bug, you may find, discuss your feature requests among one another and also tell us what you like about the changes we already made (especially this part is thousand times more helpful and encouraging than you might think).😉

Keep in mind, how this feedback will be prioritised is up to the development team.

Best regards
Mathias

Unfortunately, I haven't had the time yet to play around with the new Vegas 15, but I'm sure the Gary and his team did a great job to make Vegas a todays and future proved NLE.

Thank you Gary & Team for keeping Vegas alive.....

@Mathias and @Gary

Thank you. Much appreciated.

As I see the Preview window gaining more "freedom" to be part of the process for me to discover my narrative, I can't wait to see how your ideas showing-up for the future.

Sounds like MAGIX/Madison have beefed-up the salaried programmer roll-call? Yes? If so, this is good to hear.

We've all come a long way - haven't we. I know I have. And guess what, couldn't have done it without VideoFactory, DVDA, SF and VegasPro. (oh yes, and Cinescore .... )

A year in software development is a very long time. Magix opted to do very little and spend as few dollars as possible to bring Vegas into the modern era. They did nothing to substantially improve color correction. No improvement in media management or stability issues. It is almost as if the developers have not looked at the true professional products on the market such as Premiere. DaVinci Resolve or FCPx.

As usual, I'm blown away by the passion you all show for VEGAS Pro. I sincerely appreciate those of you who contribute here in a constructive way. I'm sorry for your frustrations when you discover something that disappoints you. That's the nature of development and the very prioritization balancing act that I have been working through. Sometimes I suppose I get it wrong, but hopefully we got some things right, too. I'd like to make a few specific comments that can hopefully remove a couple topics from this thread.

Thank you for the very detailed response Gary. It is appreciated. I hope you can understand, a lot of us are producers and I think we often feedback in our production style. I think most of us are constructive in our outlook, even though it may not always appear so.

Re: Hamburger menus. Some of you are missing the point. As Marco pointed out, these are about giving you the freedom to totally customize your workspace with the tools you use most often front and center. I am quite stumped to understand how giving you this type of workspace flexibility is in any way a bad thing, but I could be wrong. Yes, if you want a one-click path to minimizing your tracks, it take a couple extra clicks, the first time. But once you customize your track headers to show your minimize button, it is one-click from there on out. Forever. Unless you change it. The hamburger systems seems to me to be far superior to cramming yet more into the bloated right-click context menus. It is completely configurable so you can get exactly what you want instead of what we shove down your throat. I don't get how that is in any way a bad thing.

I think the thing with the Hamburger system is that the userbase has not been sufficiently primed for what could be a very powerful and useful feature. Those of us who are working under pressure or in mission critical environments are not always welcoming of change, even when the potential is great. I suspect if there had been some videos issued demonstrating how to use it a few weeks prior to release when we were hungry for information, and then at the end of the video it said "and if you are not ready to integrate this into your workflow yet, here is the button that switches to the legacy behaviour" it would have been much better received. When we upgrade there is the financial investment, and we also have to schedule to invest time into learning what is new. I think a lot of the anxiety relating to the new release is about things changing and still being able to do what we could do before. I think a lot of us worry about having to make unscheduled investments into figuring out why things are not doing what we expect them to, or if things creep through to final release of our productions.

Which leads to the point about beta testing, which I think was in response to my comment on the 0db being in the wrong place on the meter. I did not want to sound like I was criticizing the individual beta testers. I get the impression that audio features could be getting slightly less attention than video features in the beta testing rounds. I am probably off beam there. The thing is, like a lot of producers, I am a man of very little appreciable creative talent, but I am fairly good at pointing out mistakes in detail; So originating from an audio background, if I saw waves presenting on screen looking off-centre to the meter, alarm bells would be ringing and I would immediately be leaping ahead panicking that that there is some biased hum or other noise polluting my precious audio. I find it hard to understand how other producers would not catch that, but then there are plenty of other audio bugs that have made it into release that I have not noticed. And bug do get into releases, and it is reasonable to expect bugs to be found and addressed after initial release. The 0db marker just seemed like a sitter that is right in front of the user's face and it just made me think "Oh, this software as released has not been in front of a dedicated audio engineer".

 

Re: the new PinP and Crop plug-ins. I can't tell you the number of requests we've gotten over the years for the ability to manipulate your video directly on the Video Preview window. As we investigated how to do this, it became clear that attempting to force the rather convoluted Track Motion and Event Pan/Crop code into doing this would be a huge effort that in the end would not provide the quality of result you demand. These new plug-ins are flexible (you are no longer restricted to creating a PinP only at the track level), and simple. How many of you even ever figured out how to do a true crop with the Event Pan/Crop tool? Did you even know you can create a true crop with the Event Pan/Crop tool? Those tools are clunky and about as non-intuitive as could be. The new plug-ins are easy, flexible, and do exactly what you'd expect them to do.

Again this is one of those things I think could have done with a good heads up prior to the release with a visual demonstration of the feature. I can see the benefit in this, but reading from the feature list it is not obvious what the difference is to the event/pan features, which has made it a little confusing, particularly when people are scanning through eagerly seeing what has 'New' listed next to it. The 'Paste Selected attribute' function was something I had asked for years ago and I am happy to see it, but I am not necessarily enthused by it. I can have that hammer I always felt I needed if I choose to go ahead and buy it.

Re: "Why did you waste time on things like freeze frame when there is so much other stuff to do?" You have to understand a little about how development works. We have a talented, but small, team of developers. Each of them has a particular area of expertise, even as they are extremely flexible and willing to work wherever the code needs them. We have experience ranging from senior developers to junior. A couple of points to be made: #1 they can't all be working on the same area of code at one time. #2 a more junior developer may not yet be capable of working in complicated areas of the code. The freeze frame and selective attribute paste features are perfect examples. Some have complained that we "wasted" our time doing those. On the contrary, those were great features for our most junior developer to tackle, and both of those features have been requested countless times by you users. He did a fantastic job, you got two additional features that the more senior guys didn't have time to do, and because of the experience, our junior guy is now considerably closer to being able to work on more complicated tasks in the future. Any way you look at it, these features are a great win for you in the end.

I think the freeze frame is a great feature and addressing a long term need. In the wider context when the audience were eager for other features that have not quite arrived it was a bit deflating to see it touted in that 'New' list. It is very encouraging to hear that Magix are recruiting and developing new talent and expanding the team. I think new blood can only help the future development of Vegas and i wish your junior/s all the best. There are certainly a lot of features the userbase are after that would be suited to a developing developer (I think there was a request for multi-coloured markers elsewhere in this thread, certainly something that would be handy to myself)

Well, I'll stop now. I hope I cleared a couple things up for you even as I understand that some of you will now follow up by saying, "Fine, but you did not answer _my_ question." I get it, and sometimes I just need to ruminate on the issues before I comment further. Other times--particularly when the tone is rude and it seems that there is no answer that I can give that will stop the rudeness--I just need to let the discussion play out a bit before I jump in. In the end, here's a tip: being rude, disparaging our developers or beta testers (or anyone else involved), and posting endless threats to jump to a different tool are not nearly as likely to get you a measured response as is respectfully asking a question or stating your frustrations.

Thanks for listening...sorry for the long post.

The only thing i am genuinely disappointed about is that I was getting email after email encouraging me to buy the Vegas 14 upgrade even after the Vegas 15 announcement was made. On top of that every email seemed to be suggesting a better discounted upgrade price than the last, when the upgrade pricing was actually the exact same on every email. That made me angry. I do not understand why the upgrade to 14 was still being offered and pushed after the Vegas 15 announcement, and still available until 21st August. From what I understand the default position is for those who upgraded to 14 in the last few weeks to pay the normal upgrade price to get 15, with maybe something else offered if they contact customer services direct. I did not take the Vegas 14 upgrade, but that whole thing I did not like. That seemed sneaky and it is something whoever is responsible needs to look at in future.

Thanks again,

Robert

Re: Magix update here via Gary - (browser won't let me officially quote Gary's post on last past and submit sorry):

--
Re: Event headers. The beta testers gave us great feedback on these. Among them there was virtually a 50/50 split on whether they loved them or hated them. Based on their feedback, we have already coded the option to turn them off into the first free update to VP 15. For those of you who land on the "hate them" side, I'm sorry I can't get this option to you sooner, but in the not-so-distant future you will be able to turn them off and still have complete access to the hamburger menu system.
---

^^^

Thank you so much for this quick implementation (forthcoming) and reply. Faith in Vegas restored. So far I love the speed of V15 I just need to make sure my workflow will translate to this version. I have multiple 3hr projects in V14 and at the moment I wouldn't feel comfortable opening them in V15 to continue/render out. I know I'd make an error here or there moving a clip when intending to just move an envelope. Further I think I'd miss stuff due to the bar and default timeline color (could be my old eyes but they're not appealing). I think if there's a way to make it look more or less like V14 I'd be in love. Thank you for reading our opinions and understanding that we're all just passionate about the software. Glad to see you guys are hands on. Cheers.

Thank you for your great feedback, Robert.👍

The only thing i am genuinely disappointed about is that I was getting email after email encouraging me to buy the Vegas 14 upgrade even after the Vegas 15 announcement was made. [...]

This is something I will address internally. Sorry, that I can't comment further on that.

I haven't installed VP15 yet, but there's nothing in the press release about adding support Panasonic's new UltraAVC codecs (well, new - it's been a while). So I'm guessing that's still not working?

It's working.

No, it's not. Just installed VP15 and none of the Panasonic Varicam files could be imported. It seems the scope of importable video files still hasn't changed...

AVCintra files from professional Panasonic products are not some kind of obscure format - and every other NLE out there supports this : http://pro-av.panasonic.net/en/avc-ultra/intra2k4k.html .

I do love working with Vegas Pro, but I (and many others) have been asking this for such a long time. Converting up front is an enormous hassle. If Vegas Pro still wants to be considered as one of the possible pro editing options, it should at least make this list. This is a letdown. Is support for Panasonic pro even planned?

 

Now that we are so honest about a development path and priority within this list : Is the Pana Pro support even somewhere on that list? I was told this was on the list last year, but I'm guessing priority must have been very low.

Even then, if we have to wait 2 years for compatibility to be offered, by then the equipment and codecs have probably changed again.

(An with half of the Netflix content shot on varicam, this seems a here-and-now thing...)

I am sorry if it was maybe me making comments on the software development but to be honest, if I may, I find the quality I see in this version, build 177, quite below from what I would consider professional development like I saw in the past with Vegas. Ofcourse junior developers are excused, but for the rest of the team, I am going to mention here two points, firstly if there was this 50/50 percent like/dislike about the event headers, and you have already coded this option in to turn it off, why then isn't this already available in build 177, (professionaly) anticipating 50% possibility for dislike of your customers and having already a solution ready. Secondly, if I see that the envelopes and especially the 0 dB position do not respect the event headers, then, how would you like to call that yourself, Gary? I think you must be able to see this in 5 minutes. And so, if Matthias is upset that Gary "stole his thunder" how would you like to call that yourselves under these circumstances?

Next, I am greateful for all that I learnt from you Gary, because when I started I knew almost nothing about video editing, but I know a bit or two about software development. I was sorry to see that Sony sold off Vegas, and it is my impressionan and that saddens me, that somehow that great creativity which was there in the beginning died off. Sometimes this happens due to decisions higher in the organisation, where sometimes good things are killed off for the wrong reasons. I hope, that those developers who were the driving force from the beginning and I recognised their professionalism, are ok under this reorganisation. Where ever they may be now.

For the rest, I did not see for me personally any valid reason to upgrade from Vegas pro 12, but fine I would be willing to if I am certain that the former development team is ok, and so I am not taking advantage of them, and the product meets a certain professional standard. At this moment, I don't know how long I have to wait for that upgrade to turn the event headers off, because even if I would like them, I can not accept the fact that the envelopes are not adapted to this, and so turning them off at this stage is not a feature for those that do not like them, but a work around to hide the fact that the envelopes are not adjusted to them.

And so, I hope I can see this workaround still within my 30 days trial, or request a new trial when this build will become available, because honestly, to go ahead now, just in good faith, and buy this version anyway, I am kind of reluctant because that is not what a 30 days trial period should be about, and finally, I do not like the fact how Vegas 14 was still being pushed to the last possible moment, while Vegas 15 was right at the door, but we discussed that as well.

And so we will see.

Thats what I have to say about this in all honesty and I hope that's ok, because I learnt a lot from Sony creative software. But I needed to say this, also for the former development team maybe.

@gary-rebholz

You have stolen my thunder. I was just about to write something.😅

Now, I'll make it relatively short. I think, all of you can see, the development team is at least as passionate as you are. Therefore nothing which was decided to do was decided upon without great thought and consideration.

For now we are comfortable with what we decided to do and we are proud what the developers accomplished in just under a year. We're aware of all the improvements you want us to implement in VEGAS Pro. It will be a ton of work and change won't happen over night but the driving force behind this will be your requests.

So, please report any bug, you may find, discuss your feature requests among one another and also tell us what you like about the changes we already made (especially this part is thousand times more helpful and encouraging than you might think).😉

Keep in mind, how this feedback will be prioritised is up to the development team.

Best regards
Mathias

I think the crux of it is there are a lot of users that were hoping for improved colour correction and composition along the lines of what is available in Resolve, and a lot better performance on better hardware. Personally my primary concern was restoration of the Dolby Pro AC3 codec, which as you have explained was not possible, and general improved performance and use of available resources. The LUTS and ACES 1.0 support should hopefully meet my colour correction requirements (what is available in Resolve is too much for me) once I get to test it. It was really only the Dolby Pro AC3 issue that stopped me going for Vegas 14.

How much of Vegas is still tethered to VfW? Is it something that is likely to be left behind at any point in the near future for Direct X or other solutions?

firstly if there was this 50/50 percent like/dislike about the event headers, and you have already coded this option in to turn it off, why then isn't this already available in build 177, (professionaly) anticipating 50% possibility for dislike of your customers and having already a solution ready.

This feature was one of the last to be implemented, therefore the beta testers responses came in late in the cycle. Surely you all understand that not every new feature is completed at the same time in the cycle. Some are finished first, some are finished last. Next, we don't develop right up to the day of release. We freeze our release code at least two weeks before release and limit changes to any critical bugs that are found during release testing. But naturally, that doesn't mean we stop working. The day we freeze the initial release code (build 177), we start working on the first update. Internally we already have builds well beyond 177. That's how it works. The code to turn this feature off was completed after our release code was frozen and I deemed it not important enough to delay the launch to get it in. I'm sorry if you guys don't agree with that decision--perhaps it was the wrong decision--but that explains why the fix doesn't get in until the first update.

Secondly, if I see that the envelopes and especially the 0 dB position do not respect the event headers, then, how would you like to call that yourself, Gary?

Then envelopes you are talking about are track-level envelopes which explains why they don't respect the event headers. In fact, it took me less than five minutes to see this issue. I decided to go ahead with them the way they are. Again, perhaps it was the wrong decision, but I'm not convinced that is true, especially when it was explained to me how much time and effort it would take to change that behavior. I decided other things were more important, and directed the developer to move on to something else. This problem will go away once you are able to hide the hated event headers, so I didn't feel it was worth the effort to change that behavior, and certainly was not worth delaying the release.

Thank you for your kind words about learning a lot from me. I understand your frustration just as I appreciate your candor.

@Gary

Thank you for the explanatory and positive info. Quite funny: surprisingly discovering the event headers (where I am not a "hater" - but they simply make editing of my usual projects with so many compositing tracks on an only 40 inch 4K monitor impossible) - I spent the afternoon thinking: Where is "our" Gary Rebholtz - whom many of us know so well from many a good post in the old Sony Vegas forum, from many an explanatory tutorial, manual etc. etc.

And there you were - sorting out this topic / issue. Thank you so much.

More than good to know that a solution is already planned / maybe even being programmed - and looking forward to seeing it.

I really hope that the solution will be events looking precisely like in V14 - maybe keeping the right click to invoke a Hamburger-like menu (system) to set the icons one would like to have at the bottom of the events - including the possibility to opt out the Hamburger icon itself. ... ... and if I may wish further: it would be great to keep the V 15 possibility to set the icon color strength (and/or even the opacity of the icons (sorry for being so greedy)).

Thank you again.

Einar Ritsmer, Copenhagen, Denmark

One of the "old" SCVU's.

More than good to know that a solution is already planned / maybe even being programmed

It is already done. It will be in the first update.

really hope that the solution will be events looking precisely like in V14 - maybe keeping the right click to invoke a Hamburger-like menu (system) to set the icons one would like to have at the bottom of the events - including the possibility to opt out the Hamburger icon itself

Yes...and no. Yes, the events will look just like you are used to in VP14. No, the hamburger menu will not be hidable. It will always be there.

it would be great to keep the V 15 possibility to set the icon color strength

That is one of the new features of 15. See the Device tab of the Preferences dialog box.

firstly if there was this 50/50 percent like/dislike about the event headers, and you have already coded this option in to turn it off, why then isn't this already available in build 177, (professionaly) anticipating 50% possibility for dislike of your customers and having already a solution ready.

This feature was one of the last to be implemented, therefore the beta testers responses came in late in the cycle. Surely you all understand that not every new feature is completed at the same time in the cycle. Some are finished first, some are finished last. Next, we don't develop right up to the day of release. We freeze our release code at least two weeks before release and limit changes to any critical bugs that are found during release testing. But naturally, that doesn't mean we stop working. The day we freeze the initial release code (build 177), we start working on the first update. Internally we already have builds well beyond 177. That's how it works. The code to turn this feature off was completed after our release code was frozen and I deemed it not important enough to delay the launch to get it in. I'm sorry if you guys don't agree with that decision--perhaps it was the wrong decision--but that explains why the fix doesn't get in until the first update.

Secondly, if I see that the envelopes and especially the 0 dB position do not respect the event headers, then, how would you like to call that yourself, Gary?

Then envelopes you are talking about are track-level envelopes which explains why they don't respect the event headers. In fact, it took me less than five minutes to see this issue. I decided to go ahead with them the way they are. Again, perhaps it was the wrong decision, but I'm not convinced that is true, especially when it was explained to me how much time and effort it would take to change that behavior. I decided other things were more important, and directed the developer to move on to something else. This problem will go away once you are able to hide the hated event headers, so I didn't feel it was worth the effort to change that behavior, and certainly was not worth delaying the release.

Thank you for your kind words about learning a lot from me. I understand your frustration just as I appreciate your candor.

I agree with those decisions, I think it's better to give less but quality, something that works as it should. I can't wait to see what you've been working on guys, keep it up! It's true that I was disappointed but I still see potential in the software. It takes time but if the team keeps working on it passionately as they do it now, then it can become a very hardcore editing software that we've never seen before. :D

The only thing I really expect is stability, I don't want the program to crush for a simple CTRL+Z - undo. :)

Re: Event headers. The beta testers gave us great feedback on these. Among them there was virtually a 50/50 split on whether they loved them or hated them. Based on their feedback, we have already coded the option to turn them off into the first free update to VP 15. For those of you who land on the "hate them" side, I'm sorry I can't get this option to you sooner, but in the not-so-distant future you will be able to turn them off and still have complete access to the hamburger menu system.

If that effectively means that video event controls (fx, pan/crop etc.) can be overlaid on a VP14-style minimized track (i.e. with mini thumbnails), that would seem like a great compromise to me, and a certain improvement over VP14. Active take information was already overlaid on those minimized tracks so seems feasible.

 I don't want the program to crush for a simple CTRL+Z - undo. :)

So far I test out, no issue with 'wild' undoing.

... and also tell us what you like about the changes we already made ...

Gladly, Sir!

The "Spica Resize" aka "Smart Upscale" is a fantastic piece of an overwhelming code, and the idea of incorporating it into the Vegas was/is brilliant & genius!

I love it's image enhancement that creates a "sharpening effect" unachievable by other means! Because of this, I can't go back to versions prior to 14.

I adore it!

* * *

Speaking exactly about VP15, the first change I'd like to seriously praise is the absence of "those little thingies" at the docked windows' upper-left corners that made windows close or un-dock if you accidentally hit 'em with your mouse.

Now I'm very much pleased to know I have to apply a whole lot more forces and efforts to "massacre the UI layout" :))
"Say No to Parkinson!" 😁

Hi, trying out the new Vegas15. Titlerpro (included in 14)...is it to supposed to work with 15 or how?

Vegas15 comes with "Boris Continuum 3D Objects Unit"...is this supposed work with "Vegas16"?

This feature was one of the last to be implemented, therefore the beta testers responses came in late in the cycle. Surely you all understand that not every new feature is completed at the same time in the cycle. Some are finished first, some are finished last. Next, we don't develop right up to the day of release. We freeze our release code at least two weeks before release and limit changes to any critical bugs that are found during release testing. But naturally, that doesn't mean we stop working. The day we freeze the initial release code (build 177), we start working on the first update. Internally we already have builds well beyond 177. That's how it works. The code to turn this feature off was completed after our release code was frozen and I deemed it not important enough to delay the launch to get it in. I'm sorry if you guys don't agree with that decision--perhaps it was the wrong decision--but that explains why the fix doesn't get in until the first update.

Gary, my feedback on that would be to suggest there may be worth exploring the possible benefit of scheduling anything that affects the general functionality of the GUI, (or may pique us producers' aversion to change) early enough in the production cycle so that the Beta testers are able to give thorough feedback and there is time to react. I know that is easy for me to say when you have probably had your coding resourcing deployed on tidying up tonnes of code that result in less clearly perceived improvements of overall performance for which you are likely to get little credit. But then I am a person who does not like things changing without me having the option to go back. In my own experience working with a coder as beta tester on a vastly less complicated frontend than Vegas, I don't think I was appreciated when they would come bounding up to me saying "I've got a wonderful new feature to show you!" and my first response, even before they told me what it was, was to say "Great, is there a way for me to switch it off... you know, if I need to?"

Then envelopes you are talking about are track-level envelopes which explains why they don't respect the event headers. In fact, it took me less than five minutes to see this issue. I decided to go ahead with them the way they are. Again, perhaps it was the wrong decision, but I'm not convinced that is true, especially when it was explained to me how much time and effort it would take to change that behavior. I decided other things were more important, and directed the developer to move on to something else. This problem will go away once you are able to hide the hated event headers, so I didn't feel it was worth the effort to change that behavior, and certainly was not worth delaying the release.

It is a difficult decision, and I am not going to criticize you for making it. I have not seen the behaviour myself yet, but as a user I would be concerned about not being able to trust my meters, and the break in the correlation between the visual representative of the wave and the previously mentioned marker, whether that was an assumed correlation or otherwise. I don't think the event headers are necessarily hated. I think they have just provoked a stronger reaction from those who do not like them. I think I will be waiting for the second build because I will probably struggle to read the header of the event anyway with my eyesight,so I will probably need to disable the feature for accessibility reasons.

I think one area that could be improved is in managing our expectations. I know that may not be the greatest thing from a marketing perspective, but when there is a vacuum on the detail on what is coming, the userbase starts filling the voice with its own visions of what should be expected. It is always going to be difficult to meet such expectations. Personally I think it is not the best strategy for the feature list to be released at the same moment the product is first available to buy. I do think to a degree we need to be telegraphed what is coming, and maybe early enough so that there can be some reaction in the codebase to our response. I know this is all easily said by those of us that have nothing to do with the development of this software. It is an expensive old game, and I don't think anyone has the resources they had 10 or 15 years ago. But I think there are a couple of things that can be done on Magix/Vegas side that can smooth things over a lot, and maybe even save you some resource and effort in the future.

You have a core of very loyal users. I still see a lot of users who were on the forums over 10 years ago. Some of these guys are going out of their way to keep Vegas in their workflows even though it has fallen short in areas they require key functionality, not just out of loyalty, but because they genuinely find the core editing functions to be the best and most productive out there. They might get angry and frustrated, but they are not doing it out of spite or because they want to upset the development team. They are doing it because they want to be out there making stuff with this tool, which is the tool that best complements their creative style.

Anyway, I am probably repeating myself. Thanks again.

Robert

I think one area that could be improved is in managing our expectations. I know that may not be the greatest thing from a marketing perspective, but when there is a vacuum on the detail on what is coming, the userbase starts filling the voice with its own visions of what should be expected.

Thanks for the insight, Robert. Yes, we've discussed this extensively internally. In fact, we did a trial this time around where I did a light reveal of some of what was coming in our VEGAS Magazine a month before release. Frankly, about all it spawned was a lot of caustic griping on Facebook because readers didn't approve of the features I mentioned. And then they had a month to stew about what they didn't like, even though they had not yet actually seen it, had no clue how it would look or feel in real life, and could not envision the value it brought. Maybe it was my fault for not being more explicit, but frankly, I'd rather deal with the fallout now when there are actual users with hands on the application that can chime in and say, "For me it is great because..." At least now we're dealing with concrete reality instead of conjecture.

But rest assured that the point is well taken. Maybe a detailed early reveal would be received differently. I suspect that no matter how we do this, passions will be stoked. I like it that way. But I don't rule the possibility of an earlier reveal in the future. These are business decisions, and they can be complicated to make.

Re: Event headers. The beta testers gave us great feedback on these. Among them there was virtually a 50/50 split on whether they loved them or hated them. Based on their feedback, we have already coded the option to turn them off into the first free update to VP 15. For those of you who land on the "hate them" side, I'm sorry I can't get this option to you sooner, but in the not-so-distant future you will be able to turn them off and still have complete access to the hamburger menu system.

Dear Gary,

just a quick thank you for the extensive feedback and an insight into your / developers' side of the Vegas world. Apologies if my comments came across as rather negative - them track headers...we, ya know...they were just puishing all my "no,no,no" buttons so badly I just didn't even feel like exploring the rest of V15 anymore because it was such a counter intuitive design to me that would have seriously impacted my workflow it it would have had to stay. In any case, I'm very happy it well be turn-offable, ( as well about the general hamburger idea, which i really like ) and that the Vegas team does indeed communicate with us users to such an explicit degree - a very promising and encouraging development as opposed to the Sony graveyard silence.

2 things from my personal wishlist ( already mentioned in another comment of mine) :

* Audio and Video tracks ( not the tracks themselves, the track section on the left ) are still too similar. Can you please make them look distinguably different?

* Track motion active / not active STILL has the 2 same almost indistinguishable colors - blue and slightly lighter blue. I can't believe I'm the only one having trouble and having to look twice to notice the diffrence. red / blue, yellow / pink whatever , but please, 2 different colors.

Would this be possible in a future release?

As soon as the headers are gone, I'll buy V15. ( the grace period thing from the late V14 buyers would indeed be a thing to consider IMHO).

Bug Report №__

The Toolbar Buttons do change unsolicited if you make changes to the "Script Menu" folder (add/remove files).