I have uploaded my app on 21 Nov 2024 (and did a second submission today) and its status is still in pending manual review. Could you please provide an update on its progress and let me know if there are any further steps required from my side?
Yes, the app uses the personal-files interface to request the access to those folders.
The app is a DAW (Digital Audio Workstation) and one of its main features is hosting third-party plugins. The folders the app needs to access are some of the user shared directories where third-party plugins are typically installed.
Thanks, @andrescudo ! One quick question: Since these directories are used by third-party plugins and the user needs to load these plugins manually, would it be appropriate to request a manual-connect for the personal-files interface for accessing these files?
If I understand correctly, the connection to the personal-files interface is manual by default. I’m fine with leaving it manual and prompting the user to connect the interface when they want to use third-party plugins.
On this topic, I have two questions:
Is it possible to determine at runtime whether an interface has been connected or not?
Since the app, as I mentioned earlier, is a DAW and requires the alsa interface to function optimally, would it be possible to have the alsa interface connected by default, without requiring the user to connect it manually?
To determine if an interface is connected from within a snap you can always use snapctl is-connected <interface name> from some script or the app itself… It will return true when connected and false if not
alsa interface is fine given the nature of this application. +1 from my end for auto-connection of alsa
and +1 for manual connect for the personal-files interface on the given files in $HOME dir
+1 from me for auto-connect of alsa for n-trackstudio. Also +1 for use of but not auto-connect of the associated personal-files interface. However, given that we expect the user to now connect this manually, I think it would be better to split it into 3 different personal-files instances, each named with the associated path. ie.
If I’m right, the different folders .vst, .vst3 and clap refers to different plugins formats (host-plugin API actually). In general, I don’t think users decide to use one or the other but use them all for different plugins.
Considering that the three folders are intended to provide the same functionality, I would be happy to stick to one single interface in this case, in pro of usability.
@andrescudo you would be best to provide guidance here on what you think is more appropriate - to either split this into separate plugs or have them in one single one - really whatever you think is going to be most intuitive to users since they will have to manually connect the interface.
The .vst, .vst3, and clap folders indeed correspond to different plugin formats, and many users don’t pay much attention to the differences between these formats, which often stem from implementation reasons rather than anything affecting their final use.
As a user of plugins and DAWs, I don’t see any reason why I should want to access one type of plugin over another.
Sticking the access to these folders to a single interface makes perfect sense, would undoubtedly improve usability and simplify things for the end user.
Thanks for the clarification - so that sounds reasonable then, let’s go ahead with the current plug declaration that includes all 3 paths.
+2 votes for, 0 votes against, granting use of but not auto-connect for personal-files named audio-plugins-user with read permission to $HOME/.(vst|clap|vst3). This is now live.