I think there’s some kind of middle ground here, where Autodesk builds partnerships with certain post houses.
Those places get discounted rates for running the beta with the help of a specialized support team from Autodesk. I have a hunch that bugs often aren’t discovered in Flame because the testing that goes on at Autodesk simply can’t replicate the actual working environment of a post facility.
That no longer makes that much sense since the changes made in an Update can be as big as changes made in a “major version”. I think this is mostly a legacy feeling that is still around after many years.
I’m not saying it makes a ton of sense. I’m just saying thats how people feel.
The problems that exist in older releases become a known quantity after a period of time. People come up with workarounds and tricks for addressing the issues. They learn about the issues from colleagues and they try to stay on a release which is generally regarded to have fewer issues.
What they’re afraid of is moving to a new version where the current issues are entirely unknown and liable to bite them in the ass right as they try to deliver a job.
I’m not claiming that there is some great marginalized community of Flame artists. We’re all doing pretty well as far as I can tell. That said, inclusion is about meeting people where they are and not about asking them to come to you.
If we know that the vast majority of Flame users aren’t interested in engaging with Autodesk, the onus is on Autodesk to fix that, not the users. If it is known that there is a legacy feeling of distrust lingering in the community then it seems like it would behoove Autodesk to do something about it.
We’re a superstitious lot and that superstition is born in large part from not understanding how the software works on a fundamental level and repeatedly ending up in situations where we feel entirely beholden to the unknown and seemingly capricious whims of a software which forms the basis of our livelihoods.
This may be a softball question, but I’m curious what “a day in the life of a flame dev” looks like.
I’m curious how much time the developers spend testing on Mac vs Linux. I’m sure you do the same QC checks on both platforms but which one do you sit in front of all day?
Then def join in on Sunday if you can! I just did a run through with @frenetj Jasmin Frenette and he’s invited two other senior software developers to join him: @JasminRoy and Mathieu Sansregret. They’ve been monitoring this thread and are ready to discuss a number of the topics that came up. I would like to stress again what an excellent opportunity this is to look at the development process and speak with the developers themselves.
My question is: What is the vision for the future of Flame? A big question I know, and maybe to boil it down to it’s essence - what is the objective for Flames place in the wider market when compared to it’s competitors? Software and use cases evolve, new entrants disrupt, technologies change. Many of us are not the “traditional” archetypal users of what Flame once was - facility bound and and playing a role within a larger architecture.
I suspect this might be true - but is the aim for Flame to be even more well rounded in terms of non traditional workflows - motion design and more stylistic work specifically? I feel that there is so much potential there - but the bedrock of those capabilities seem to be somewhat neglected (particles / text etc). Going through the old logik videos, there is such a wealth of people doing unorthodox work with Flame (David Crites film installation work - GPM‘s wonderful shenanigans - Sam Edwards cosmos work)- is there an intention to develop these feature sets more? Apart from the obvious and previously mentioned particles rework - things like procedural shape layers that would mean not having to smush gmasks into doing things they’re not supposed to. Or a randomiser for parameters in the replica node. I realise I’m probably talking from the fringe, but would love to hear the devs thoughts on us here in the peanut gallery.
(Also I will beta test the nonsense out of whatever you give me - I publicly declare my volunteership)
Same comment as mentioned earlier: this is not a question for the developers but for the product managers.
If you are interested in being a Beta Tester (great!) please send an email to martin.beaulieu@autodesk.com and mention you want to join the program.
Fred maybe you can help me understand since I am not that bright but how does the dev team get its marching orders on what to develop does it go from votes on the website to assimilating to managers to decide feature requests then the development team implements them as they see fit kind of deal? If that is the case does the dev team have a bigger outlook on how to develop the software to do major overhauls in say a two year or five year outlook. If I am way off base I apologize and by no means do you have to explain how the hierarchy of decisions are made but it might help understand the questions I should post for each corresponding team?
oh and I forgot, Go Bills!
How we operate is pretty standard. I will summarize it as much as possible…
Product Managers are responsible to identify what problems they want to solve / markets they want to grow.
Product Owners/Designers are the link between the PM and the dev team. They are responsible to define how to solve the problems.
Developers / QA are responsible to implement these solutions.
That being said the way we operate in Flame is very collegiate and persons from each team are involved throughout the process. And there are always exceptions. The Developers do not need the Product Owners to tell them what to do to support Apple Silicon for example.
So here would be one question for a developer that I might ask, when working on particular features and implementing those are there features you wish would be addressed that might not be on the problem list from the manager or the designers? ie rewriting parts of the software that have been left dormant or certain optimizations that you wish had time to correct?
Would you mind expanding upon this a wee bit por favor? What does Autodesk do or not do that makes you feel this way? And perhaps more importantly, why does this matter? From my position it’s a business, right? I mean, they ‘care’ about us enough to make a software we use so we can put oat milk in our fridges? They make software. We either plop down our credit card or not. Right?
I think, first with the Logik on FB and now this forum the senior developers (@fredwarren and @Slabrie) and the community managers (@YannLaforest and @robert.doche) have brought us users and the dev team much much closer than it was before, especially for non-US users.
I also think they put a lot of their personal time into engagement with us and I, for my part hugely appreciate that.
They do have to abide by corporate rules but they go above and beyond what they normally should do.
I think this is something that already goes on in the beta community. There are some beta testers who exclusively use the beta versions in production. If they have problems they report them on the beta forum and get the necessary help. The beta software is provided for free, aka, discounted rates.
Although Autodesk’s website primarily focuses on products with large user bases, it does not mean Flame is not important to Autodesk. Plus, there is no correlation between this and the product’s current and future longevity.
As a reminder, Flame will soon turn 30 and has been an Autodesk product since 1999. Very recently, Flame has been one of the first Autodesk products to run on AWS and integrate AI-ML technologies. Flame is still cutting-edge and very innovative.
Some other “smaller” products under the Autodesk umbrella have less exposure and visibility than the flagship products. Still, it does not mean that they are not important in the Autodesk ecosystem.
Best,
Yann
I think I misspoke here. I believe you need to have an active subscription in order to beta test. Apologies for any confusion!
Hi @andymilkis,
To be specific, you either need to have an active subscription or be employed by a company that has an active subscription to be eligible for the Flame beta program.
Best,
Yann
i would ask why not all options in the Preferences are carried over to the next project as a preference?
eg - Viewport Monitoring always seems to be activated on new project creation, so i always have to switch it off again. That preference is never remembered.
That’s because some settings are project-based and some others are user-based. So the ones saved with the project are not kept when you create a new one.
Be good if the preference area was split into the two categories