I understand but again the same amount of work could be achieved by a team of 2, 10, or 30 depending on many different factors. There are so many examples I could give…
If product A has 10 QA/Testers but no automated test and Product B has 2 QA/Testers but a complete suite of automated test the 2 vs 10 doesn’t mean anything. It is simply not possible to compare the numbers again anything.
If product A uses an agile development method they have scrum masters for their teams that count as head counts in the development team but do not impact the product directly. If product B uses a different methods it is more likely that they have less head counts geared for the team’s productivity only.
Autodesk has more than 10 000 employees… I can tell you that from a pure number stand point Flame is a drop in Autodesk’s business. No matter if the number is 5, 25, 50, 200, 350… it is just a small part.
Micro-Freezes: When we are able to reproduce issue related to this we are fixing them right way.
GUI corruption: I can only think of one issue and we we got the steps to reproduce it we fixed it right way.
I am not totally sure what you mean about the Motion Vectors instability but we have made improvements in the last year. I saw reports about potential Memory Leaks associated to them but I don’t know if this has been reported to the support team or not. Also keep in mind that the instability could come from using graphics cards that are not certified.
“This new issue with timeline keyframes in 2023 that @creonovo and @dlevine just pointed out the other day”. I haven’t seen that one pass by. Has this been reported to the support team?
“the resolution and aspect ratio problems that @ALan brought up recently”. We have already fixed some of these and others are scheduled to be fixed soon. Many of these bugs have been in the software for years and only Alan have reported them in the last year. We can’t fix things we are not aware of and we do our best to fix them when they are brought to our attention.
All of the above was not a defensive stance on my part. I wanted to highlight that many of the things you are mentioned have been looked at in the past year which I thinks give you a better idea of what is going on than how many people could have been potentially looking at them.
People were scared because we could only show the FX clips in the Effects tab and people thought they had lost their media. We decided that having two separate spaces would help this
We wanted something that could hold different things than clips. We wanted to work on the Reference Grab Buffer and thought that having an are where you can store references and fx that is available throughout the application (and that can’t be confused with the media) would be a good thing. That new area is the Explorer.
Fred,
Speaking to the timeline keyframes issue we are seeing, I hadn’t reported it yet which is why I started a forum post. I wanted to check that I wasn’t missing a filtering option somewhere before logging it as either a bug or feature request.
Since this seems like it might be a bug, I’ll go ahead and submit a report.
tbf head count and how stuff is done internally to me is just plain up interesting cause I am a nerd.
Its not for me to judge the performance of such team, its just more human to know "there are 5 awesome coder nerds working on flame, having meeting ls about what festures to put in and whatnot, just kind of like watching a behind the scenes of a movie.
I just find it interesting thats all really, every movie has a credit roll, why cant we make the developers into the rockstars they deserve to be instead of having this big mysterious “autodesk giant” doing something. Oh yea “Lana is the one that did the bew text module” . Idk probably its all business relevant and cant be disclosed yadda yadda… I get it.
thats really all for me, I just love openness as we are such a small community, sharing is nice and fun.
That’s totally fair and I don’t mean to take issue with the actual dev team. I know that you all are working your hardest and that you all care a lot for the program. Your and your colleagues’ participation in this forum is ample evidence of that and one of the things that dramatically improves the quality of discussion around here.
My argument isn’t actually about the dev team its about Autodesk’s relationship with Flame.
Its great context to know more about the software development process since I don’t know squat. I really do take your point that there is more to it than the absolute number of people working on the program. My point is really that the more resources are put into the software the better it will be.
I don’t know what the situation is, but I would love to have the two guys who’ve been working on the software from the beginning and the 10 that are freshly out of school, and the 10 QA testers, and the complete suite of automated tests, and the scrum masters, and everything else. Ideally Flame development would have it all and for every one of those things that it doesn’t have it is worse off than it would be if it had them.
So the number of people working on the team is less meaningful since some resources are better than others, but they all get paid in money and the more money ADSK spends on Flame the better Flame will be. Its not about people per say, but about the level of investment that ADSK is putting into the program. We’re all asking the wrong question about how big the team is because we’re trying to get at how much money is going into the program. I know that ADSK isn’t going to come out and say we spend X money on developing Flame, but there is a chance that someone will mention how many people are working on the program. Again its one variable that is an index of the level of investment.
I appreciate that the dev team is responsive to issues as they come up, but when you treat the problems reactively instead of proactively the users get the short end of the stick. Relying on us to point out issues in the software is effectively outsourcing one aspect of the program development so that Autodesk can invest fewer resources up front in the software’s development.
I understand that this happens with all software and that realistically not every bug can be caught and fixed before a release. What I find troubling is the number of “showstopping” bugs that have come up in recent years. How is it possible that the GUI corruption made it through testing into a release? It just should not have happened. Its incredibly easy to replicate, and occurs when doing one of the most core functions of action. Literally what is the point of action if I’m not going to use it for multiple outputs? If I’m just putting A over B and using a single action output then why wouldn’t I just use a comp node?
I can’t help but feel that if the development team was bigger some of these issues wouldn’t be making it to the users and that gets right back to how much money Autodesk is putting into Flame.
There used to be a credit roll easter egg for many years (under the Timeline) but we had to remove it… I guess that gives you the answer to “will we disclose how many people are in the Flame team”.
All of that is great. There are a lot of people here who are really happy with the explorer.
I’m just not sure why making it impossible to drag bfx to the desktop was a necessary part of this. Especially since it can still be done. I’ve had conversations with at least half a dozen artists who are still dragging their bfx to the desktop. We grab multiple clips on the timeline, copy them out, and then go in and delete the extra clips until we’re only left with the bfx. We’re still doing it the old way but now we have to take a bunch of extra steps to do it.
Its awesome to be getting new features, but I don’t understand why we’re being compelled to change the way we work. Can’t the explorer coexist with the old way of copying bfx? In the past its felt like development has largely proceeded along the lines of, “Here is a new feature, but you can still do it the old way if you want” and this feels like a change from that approach because there is literally an arbitrary roadblock in the way. It feels like the approach is, “we’ll let you do it the old way but we’re going to make it painful enough that you just give up and do it our way now.”
The idea was to avoid mixing Metadata items with Media items because it was creating confusion amongst some users. This is why you can drag a clip (Media with an FX on it) but not an FX (Metadata only).
@andymilkis Sorry if I derailed that thread. I hope it still gives an insight of the development process.
It’d been possible forever to copy empty tlfx to the reels, and was something I used to use all the time. While we’re talking about it, can we please copy from the timeline directly out to Shared libraries again? That went away around when the Explorer showed up, too.
Yeah I get why Explorer is there. But I don’t get why the old functionality was taken away. I used this feature constantly and I wish it were still there. I was never confused about anything related to this. It just worked and made sense.
No worries, Fred. Now I’ve never been more excited to plan the upcoming “The Pets of Logik” show!
All kidding aside, thank you, as always, for being such an active presence here on the Logik Forum! And you are 100% right, that this is an insight into the development process. I’ve been a beta tester for almost 20 years. I can tell you all from experience that none of these changes come easy, and none are decided in a vacuum. Ideas are proposed and feedback is given. Many times things have been changed in beta based on user feedback. I’ve seen it! I’d encourage everyone to consider participating in the beta program. It’s incredibly fulfilling!
Progress always has its challenges. It’s been discussed numerous times here and elsewhere. Remember how everyone freaked out when keyboard shortcuts were upended with the Anniversary Edition? Or how many of us tried to force “the old way” on to a new paradigm, only to grow so frustrated that we adapted? Is Flame a better app now? You certainly don’t have to like all the changes but an incredible amount of time, thought, and (dare I say) love goes into each and every one of them. We have folks on the Dev Team who have been with flame for over 20 years. They live and breathe this product, just like the rest of us.
BUT GETTING BACK TO THE ORIGINAL TOPIC Have you ever wondered what actually happens when you press render? What is the processing pipeline like? How hard is it to change the infrastructure of a 30 year old app? Instead of asking again and again things like, “How many people work on the Flame Dev team?” how about questions like what type of skills do you look for in a developer? How has that changed in the last 5 years? What feature or change was surprisingly easier to implement then you first thought? What was the hardest? How long did it take to develop the SLAM tracker, from first proposal to delivered feature? What benefits did the AWS implementation yield to those of us who have local machines? How many feature requests do you get in a calendar year? How many are implemented? How was Flame development affected by the supply chain issues? Can you talk more about the automated QA systems that you use? Have you ever had to kick back an API from a camera manufacturer for something that didn’t work? If so, can you say what?
By all means, give feedback! Speak up when you find a bug. I found one yesterday and have reported it to Flame Feedback. But the intention of this thread, and this weekend’s show, is really to dive deep into how the sausage gets made.
This has been discussed ad-nauseam everywhere. There is a GPU memory leak in MotionVector Tracking code that will eventual (often soon) crash GPUs that have less than 48GB of VRAM. It happens on officially supported Quadros.
I never saw that one before. Please make sure you report it to support but my guess is that it will be hard to reproduce on our side if you cannot reproduce it at will on your side. Can you?
I have reported it to support, provided the full archive. On my P620 with A6000, it is 100% reproducible in some fashion. I eventually gave up, and rendered it on a z840 with RTX8000 without issues. Go figure.
Helping get back on topic though, here are a few questions that I would like answered about Flame development.
How much time/resources are devoted to fixing bugs and other maintenance and how much time is spent developing new features? Is one side being prioritized over the other and how is that decision being made?
Do you believe that the Autodesk Feedback community is representative of the larger Flame community? Do you ever worry that only the loudest voices are heard when taking on user feedback and using that to set development priorities?
Do you believe that the Beta testing group is representative of the larger Flame community? Do you ever worry that the priorities of the beta testing group don’t align with those of the broader Flame community?
Are there any plans to draw a wider cross-section of the Flame community into its development? Would Autodesk consider recruiting a larger group of artists to whom decisions about development might be proposed prior to their development and inclusion in the software?
What is the QA process for Flame? Does Autodesk directly employ any Flame artists for the testing process or is it entirely reliant upon voluntary reporting from the beta testing group?
In the recent past, it seems that new feature development has tended to favor timeline features. How are priorities between development on editorial/timeline features and compositing/batch features determined?
What is the roadmap for further development of integrated AI features? Are there any plans to add a feature similar to Nuke’s copycat?
Flame’s ageing userbase is a frequent topic of discussion on the forum. Is this also a topic among the development team and how, if at all, does a declining userbase affect the roadmap for Flame development?
How long is the roadmap for Flame development? Does it look one year into the future? 3? 5? 10?
Flame famously has a million and one ways to do something, however recently we’ve seen certain ways of working curtailed as new features become available. Does the current approach to development favor “streamlining” Flame by replacing old methods with new over adding functionality without removing legacy modes of working?
Recently, we’ve seen a number of changes to Flame that are part of a larger reorganization within the Autodesk ecosystem, changes to UI, licensing, trial products being just a few. Do you anticipate further changes to Flame that will be mandated by Autodesk without regard to the specific needs of the software?
What might be some possible barriers to adding automatic archiving functionality to Flame? Is this something the development team might consider or are the variables too many for it to be considered?
Since the covid-19 pandemic, the proliferation of remote work has dramatically changed the conditions under which many of us use and interact with Flame. This has at times led to reduced functionality. Does the development team have open channels of communication with Teradici and what, if any, work is being done to ensure that Flame is stable and interoperable with remote work software?
Are there tools within Flame that, for whatever reason, will never be reworked or improved in the future? What might some of them be and why?
If they can be shared, what are the dev team’s current priorities?
