Dev Talks: Why We Transformed Native Access
Comments
-
What I'd love to have is the "Files" section in Native Access. This would be the place where all template/configuration files are saved/located and available to download or send to Controller Editor. Just a tought.
2 -
This is a very interesting suggestion! I'll make sure to note it down and bring it into team discussions! We've had some preliminary discussions about how we can empower users across the Soundwide Ecosystem, so it's good to know these are discussions worth having. Same goes for your suggestion Stevan!
5 -
Any reason devs went with Electron instead of something like Tauri?
2 -
Ok! Nice to see a plan. I guess I’ll wait to update. Windows 10 Pro user here.
1 -
Happy to indulge! Our startup process needed to accomplish a few things:
- Checking if the user has logged in/logging the user in
- Installing/Booting up the Daemon
- Looking for the user's products/purchases in our databases
- Get all the product information for every product
- Activate the user's products in accordance to the activation state
- Fuse the data together, and filter out products that weren't installable
- Refresh the product states locally based on any potential incoming information
I might be missing a few smaller tasks here, but that's the gist of things. It's all a result of a combined effort from 3 different teams (Daemon, API, and NA2) to make this a reality and improve on the previous version. While NA1's startup flow is also not ideal, our launch version was definitely not in the best state. Some issues we uncovered were:
- Adding a Daemon to the mix added more challenges than we anticipated, as well as an extra step that we cannot circumvent that naturally prolongs the startup times compared to NA1
- Our authorization detection and permission systems were flaky
- All steps were happening sequentially, when some could be done in parallel.
- All of the user's products were being reactivated. This is one of the largest culprits.
- All the products' statuses were updated in our servers to the results of the activation step
- All of the products were then refreshed which would retrigger the activation step unintentionally in some cases
- Our data handling was linear and we needed to control exactly where the data was going. This was another major culprit.
- There were excess calls being made as a result, which overwhelmed our servers at times, especially in cases of high traffic
We decided to go ahead anyway as we already stabilized in Beta to a slightly more satisfactory state, though we were not happy with the state. We planned to kickstart a major overhaul, which we thought would last a quarter. As such, we made the decision to release with goals to go to a "3.0" state soon after. We're still convinced that adding a Daemon alongside a GUI is the right way to go as it makes a lot of things very flexible, for us as well as the rest of the company. We've addressed most of the above pain points with 3.0.0. Now we run things in parallel where it makes sense, eliminated the excess calls and reduce unnecessary traffic, our data management overhaul made it so the data itself reacted to updates handed to it so that more edge cases were addressed, and our next iteration coming within the next two releases will address how and when we activate products. Initial testing shows very promising results for all startup times following the initial startup, for which the extensive duration is due to the Daemon installation and the initial activation within that newly installed daemon.
2 -
Appreciate the feedback and insight. Native Access 2 is not intended to work like other products. We're in a position where we can release more frequently than we would like. This means we're able to address individual issues as we fix them within the span of a release cadence, and can switch feedback more frequently. We don't put them in bulk as that would slow down our ability to iterate on various other parts of our app. I fully sympathize with the frustration. We'll look at retailoring the version number.
2 -
So this was before my time, so I'll do my best to discuss the details.
Specifically, the vision was a collaborative effort with multiple teams, not just NA1's and another web dev team. We had the idea to build a GUI using web technologies (which I see Tauri does as well) that we could componentize and theme up in an effort to support the future stacks. We wanted to fully separate areas of concern in our stack, from front-end components to back-end services. To make it work with the rest of our web tech stack, we wanted to levy the front-end framework React, which Electron's builder supports out of the box, as the rest of our web stack makes use of it as well. Electron also served all the needs we needed: auto updates, background worker we could channel things through that operated in NodeJS, a separated renderer environment for UI-specific code, a bridge to communicate between the two environments, and webpack to bundle node libraries together, which we needed for our communication bridge between the NTKDaemon and NA2. We do experience some growing pains, such as Electron having some bugs built in that we need to circumvent, and the upgrading of Electron versions is a little rough around the edges in terms of how to get there, but so far it's not blocked us off from delivering value at a rapid rate.
Regarding why not Tauri, IIRC Tauri wasn't around with a stable version until June of this year, so at the time as far as I'm aware Electron was pretty much the best option for us.
3 -
Thanks for the detailed explanation @Hayo_NI 💖
Small idea, what about "previous version" similar to steam. Where you can upgrade / downgrade or have multiple installed versions.
For example if you want to test Traktor 3.7, but still have a working shortcut for 3.5. I know right now you still have a backup exe in some directly that you need to find. But easier access through the UI might be nice for some people.
Yesterday I needed to help someone find Traktor 3.5 for a fresh PC and we could not really find a solution. (The website with old installers only had 3.4)
2 -
I have encountered a bug/quirk in NA2 when updating plugin/content. Often or always it is not possible to terminate NA using red x icon. NA announces that it is not possible as installation process is in progress. But it does not seem that anything happens. And it is posible to terminate NA using File/Exit menu.
Also it is often not possible to terminate NA using red x icon even thought nothing has been choosen to reinstall. File/Exit works....
It is on two different computers using Win10. Many past NA versions.
0 -
Hey, thanks for letting us know! In the spirit of transparency, we've got some resources already working on the download manager, and this bug is among those that will be tackled, though there's no ETA on this yet. It's not where we want it to be, for sure, so I sympathize with your frustrations here. We made a conscious choice to split the work between Daemon and NA2 for the download system so we could release faster, which results in some unfavorable situations like glitches in the queue ordering due to automatic & manual updates not playing nice with each other. In the near future we're shifting all of it to the Daemon, which will make it all a lot more robust.
0 -
So regarding supporting older versions of a specific product: No updates are mandatory for our NI products, therefore in collaboration with CS it is possible to get access to an older version of Traktor for example. We did have some discussions around this already, as the entire system around versioning isn't very user friendly, admittedly. At this stage it's lower priority though, but perhaps we can revisit this nearing the end of the year.
Regarding Native Access/Daemon older version support specifically, this poses a few problems. Daemons update functionality and offer support to older and newer OSes, which is important for all of our products. If we were to support older versions of the Daemon, it would mean newer products/versions of products are not supported out of the box and core issues linger. Our need is to be the first to support a newer operating system, and the last to drop support for one, so that all of our products are covered. To do this we need users on the newest versions, which we want to give them the best possible activation service We'd only ever drop support for an operating system if the entire company has decided to do so, which would therefore only affect older products. It also becomes a nightmare of a spiderweb for our version management. We can't update the Daemon without a corresponding/supported NA2 version, since functionality can be shifted around, so naturally NA2 is in a pickle here too.
What we are looking into is pausing automatic updates, as this is less of a pain. But it still has an effect on our supported product range, so we could end up degrading the download/activation experience unintentionally.
The TL;DR here is that it's a tricky one to tackle, but we're looking into older product version support for sure.
0 -
Yes! So it is very quirky indeed. Native Access 2 itself can in theory close during an active installation, since that process takes place in the Daemon. However, since the queue itself is stored on Native Access 2's side and not on the Daemon, closing NA2 will destroy the queue, so the Daemon will not install the next item in the queue. The Daemon does not support a queue yet, which is what we're planning to tackle in late Q1-Q2. When that's done, we also would be able to have NA2 open and close more smoothly.
0 -
Hey, appreciate the kind words and warm welcome!
- We're currently not at a point to discuss any future plans on partner integrations just yet. Sorry!
- We're sitting at around 60%, but we wont factor this in when we proceed with our migration
- While we plan to get users on modern/supported operating systems on Native Access 2, we are in the midst of discussing a fallback. There are complications that put certain users at risk and we'd like to figure out support alternatives. So we're not killing anything just yet anyway. People who run NA1 on devices NA2 does not support will be excluded from the migration.
1 -
Given how particular Maschine+ is about the versions that presets are created in, being able to revert back a few versions within NA2 would save a lot of headache and heartache. For example, simply saving a Reaktor ensemble with the current version means it will not load on Maschine+. The previous x.x.8 release is required. Similar with Kontakt. So, preventing auto-updates and easing the support team load by making reversion simple would be helpful in the context of how fragile the wider NI software ecosystem is right now.
0 -
This is great, thank you for doing the series again I can’t wait to see more!
2
Categories
- All Categories
- 19 Welcome
- 1.3K Hangout
- 59 NI News
- 694 Tech Talks
- 3.6K Native Access
- 15K Komplete
- 1.8K Komplete General
- 3.9K Komplete Kontrol
- 5.2K Kontakt
- 1.5K Reaktor
- 350 Battery 4
- 778 Guitar Rig & FX
- 400 Massive X & Synths
- 1.1K Other Software & Hardware
- 5.2K Maschine
- 6.6K Traktor
- 6.6K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators