Dev Talks: Native Access Startup Journey and Next steps
Comments
-
Hey VP.
I agree that at this stage Native Access should get you going with our products. You should be able to update when updates are available, install or uninstall products when you need/don't need them, and be able to close it.
The reason we run an NTK Daemon service is exactly so you could close Native Access when you've queued up your installations. Open, filter, queue up, close. This isn't in place yet, but we're already working towards it. The download queue migration into the NTK Daemon is one part of this vision, barring other things we need to be doing to assist that, like stabilizing the Daemon, revisiting how we react to errors, considering desktop notifications, have Native Access be able to close without quitting, etc., all to the level of being able to turn your device off then on and have the NTK Daemon carry on downloading after it starts up again, starting from where it left off.
With the NTK Daemon running as a separate service, it opens up a lot more possibilities than if we want it bundled with the GUI. Not only will it slow down development and increase the workload, but it just adds way too many restrictions too. We also want both these services to be as lightweight as possible. If things are getting out of hand size-wise, let us know so we can take a look to address that.
Regarding your locate suggestion: agree. We're revisiting the existing locate functionality right after download queue migration is done, with Locate All following suit once locate is stable. Regarding the ability to scan: we were thinking along the lines of "select a folder to scan" and for us to browse what products we found in that directory as the ideal way to go about Locate All. We'll revisit the UX near this quarter's end or the next one. We believe strongly in the feature, but it's been deprioritized in favor of storing everything.
0 -
I had a feature suggestion noted down a while ago about exporting your Native Access settings to a file, and allowing you to import those preferences. This would include:
- Folder locations for installs
- Currently installed products and their folder locations, which you would be prompted if you wanted to queue them up for installation or locate them
- Any system preferences for your existing installed products, like Traktor settings (not an existing/scoped feature)
- UI settings, like grid/tile view, legacy toggles, other setting toggles
- Any other preference of relevance.
I assumed something like this would massively improve the onboarding experience for users migrating to a different device/deprecating an old device. Would this be along the lines of what you were suggesting?
(just one note though: it would require Locate All to be released first)
Also, Uninstall is on its way. We started active dev work on it a few weeks ago. Will take us a while with the sheer load of our catalog, but we should have Content Products uninstallable around the time the next quarter rolls around, and continuing with the rest of the bunch after. At least, that's what we're shooting for.
0 -
Thanks, hope the information was insightful :D
It's a tough balance to make. While Native Access was working on revisiting the way they handled the state (3.0.0), they addressed a TON of bugs that the live version had. We could've chosen to address, for example, the massive performance issues the GUI was facing and ship those off, but the way we needed to address those performance issues in the live version would be vastly different from the in-progress version.
So what do we do:
- Ship the fix on live, then revisit it in the reworked version, which would need to import the updated live version anyway, creating extra work to migrate the live version and then readdress the prior fix differently in the new version, which totals to triple the work and thus extending the ship date even further but faster shipping of live fixes
or
- Plug the fix in the new version only, delaying the ship date of the fix but making it robustly integrated in the new version.
It's a tough call to make, cause shipping faster is always the more preferred solution, from a business standpoint and a user standpoint. The first way is something we call Tech Debt: an implementation we will need to spend a lot more time addressing later than if we were to do it properly now. We try to mitigate the amount of tech debt we need to make, but in some cases that's just not possible.
An example where we did do this was with the recent hotfixes in 3.2.1 and 3.2.2. We needed to patch the update flow so users wouldn't get locked out when we deprecated Mac OS X 10.14, if the users were on that operating system, but we should really look more closely at our update structure. Tech debt doesn't normally create issues. It's like a pipe leak. You could tape it up to block the leak, but it's just patches it. Better to just fix the pipe, but that takes more time/costs more money.
0 -
Hey D-One, thanks for the feedback and the questions:
- So far, none really. Think rather that our knowledge of the stack has gotten a lot better than when we started off, so the way we did some things are ways we aren't proud of. The Download Manager, which we built first, is an example of this, which is why we're excited to revamp it. But it's been a great dev experience so far, all things considered. Some frustrations here and there, but probably something similar would've been the case with a different package.
- It's being discussed, but I don't have any details that I could share on how, as it's all very premature :)
- Fun question to answer! Think at the moment it's 40% meetings, 10% ticket planning/organizing, 30% feature scoping, 10% research on our existing purchase to use flow, and 10% user need research (support tickets, social media, community forum, etc.). Varies a lot depending on day/month/circumstances. I never make decisions without the team being happy with it though, but the team vibe has been great lately and we seem to be on the same page, so it's been very smooth sailing lately! They're a delight to work with! Although I'm a former programmer, I don't code much anymore. Think I hacked in the release notes in the help menu and a very basic proof of concept on light mode, but that's it.
- Always eager to hear any feedback or suggestions! I could review what we can make selectable and what not. Just a little concerned about clickable elements and stuff, but release notes seems like a great use case. Will bring it to the team!
1 -
I too have this issue and have "reached out" to support. I don't think though that you have fully deprecated Rosetta in fact. If you go into the native access.app 3.3 package contents and onwards to where the NTK package is - try running that package and it asks for Rosetta. End of story.
0 -
Thanks for shouting this out, and sincerely appreciate the investigation you've done here. I'll relay this over to the team and we'll address it asap!
0 -
Okay - cool! Will you post an update?
0 -
Having Native Access rebuilt upon a cleaned up and more nimble "foundation" seems beneficial to potential strategic moves involving more SoundWide partners. And also an intriguing integration of purchasing and/or subscribing.
0 -
Well…practically…YES to first solution all the time for me. I’m sorry for the “more work” for you…but this is how things goes…
I reuse your example: if a plumber tells me “I can fix your broken pipe, but in 6th month, so I can completely change it and it will be a job done well”, I would tell him “ok, I go to another plumber who fixes it NOW”.
Sorry, but a user with water flowing into his house needs the pipe to be fixed NOW. No matter if the plumber must do more work (specially if the pipe is not perfect because of some errors made by the plumber himself: if a pipe with holes in it get mounted in my house, is my right to have the water flowing being stopped by the “distracted” plumber)
0 -
But clearly we have two different way to see things…
For me, EVERYTHING you are saying now is more important than the priorities you putted your efforts into till now.
And for my mind’s way of thinking, having to have NTK Daemon running constantly in my computer EVERY DAY when it is in facts useful only once in a couple of weeks (or in a month) only because “The reason we run an NTK Daemon service is exactly so you could close Native Access when you've queued up your installations” is absurd…
So…not having to keep a program open when it is downloading once a month being the reason for having to keep another program open DAILY when it’s not needed is sincerely OBSCURE to me. I really can’t understand this way of thinking, sorry…
It seems to me there is something more hiding on the dark side of the moon…
0 -
When I read this nightjar post the first time I was sceptical, but now (and after your answer to him and things you are saying here and there) I start thinking he is right.
And what I’m really scared of is that I don’t find the question “interesting” (nor too difficult to imagine): I start seriously thinking the reason of all this NA revamp (why even change a working program?) is only one: the cursed word for musicians… SUBSCRITIONS.
And subscriptions could also justify the need of a program constantly running in our computer. Justification that isn’t valid at all today for a program which task should be only downloading or updating ( I really don’t think users are bothered by having to keep a program open while it is doing what we ask to it: downloading something for a brief amount of time. And I really don’t even think a department like yours thinks this)
I know you can’t (and don’t want to) answer… but a future of subscription (of which we already have a taste today with the introduction of Komplete NOW (something that really smells like NI way to test the waters)) will definitely be my “GOODBYE, IT HAS BEEN A NICE JOURNEY TOGETHER” to NI after almost 20 years 😔
1 -
Yes, the devs are trying a few things as we speak. The NTK Daemon is a universal binary, which means it could be executed via rosetta, but we've removed the support for it entirely from the codebase as far as we an tell. If you're right-clicking and open the info, there should be a checkbox "Open with Rosetta". This should be unchecked.
We're investigating a little more though, so bear with us. Again, thanks for raising it. If there's anything that is going wrong on our side, we'll be sure to hotfix it.
0 -
I completely understand you here. I admit that we were prioritizing startup too much over installation success, but our goal is to stabilize the service, and many users couldn't get into Native Access to begin with. Startup plays a key role in activating your products as well, so it's definitely something we've addressed consciously in the meantime.
We've been doing a ton of research since October, and tackling a bunch of issues in the download manager, but there's still a lot of research we need to do to stabilize it even further. All of this is work in progress, and in most if not all cases is just something we cannot ship in batches even if we wanted to. We're also working on the installers at the same time, so it's really all hands on deck here. I apologize that we have to ask for patience here.
1 -
Also completely understand your frustrations with the Daemon needing to run at all times. There are too many circumstances where having it maintain the activation state at all times is important, and operating in the background to download and update your products takes time. Native Access should be closeable since it takes up space, but a download service in the background should ideally not do so.
Subscriptions solve a user problem when it comes to the entry cost to our ecosystem, but the downside is that it's hard to cater a "one size fits all" subscription with so many different types of musicians out there. TL;DR on that is simply that we're not all in on one or the other, just offering things in different ways.
1 -
We definitely feel like we'd be helping users stay focused if they were to be able to browse in a dedicated space. Native Access has the potential to do that, to keep you in the workspace. I'd love to hear your thoughts on what frustrations you have throughout your music-making journey. Maybe Native Access could help in some way!
2
Categories
- All Categories
- 22 Welcome
- 2.2K Hangout
- 86 NI News
- 1.5K Tech Talks
- 2.6K Native Access
- 14.2K Komplete
- 1.4K Komplete General
- 3.1K Komplete Kontrol
- 4.1K Kontakt
- 3.6K Reaktor
- 342 Battery 4
- 639 Guitar Rig & FX
- 329 Massive X & Synths
- 794 Other Software & Hardware
- 4.2K Maschine
- 5.3K Traktor
- 5K 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