FR: Improve refresh of external plugin presets
[edit] Originally reported as a bug, but points to design decisions.
I think there’s a problem with detecting new presets for the AUv3 plugin ReSlice by Virsyn.
[edit] Resolved. See below.
Expected behavior (works in other hosts)
- Open the standalone version of ReSlice and save a new preset
- Close the standalone version
- Open the AUv3 version in another host such as AUM
- The new preset is available
In NS2, the preset does not appear after step 3. Other user presets made before installing NS2 do show up.
Comments
A similar question came up about the iVCS3 (over in the General Chat) Abe dendy posted this
https://www.blipinteractive.co.uk/nanostudio2/user-manual/AUInstrument.html#au-compatibility
Scroll down to the bottom. Have u tried restarting the iPad?
You just need go to MANAGE tab in patch browser and hit “Refresh”.. then new patches appears in list.
(Inside plugin UI they are displayed alss without refresh, refresh is needed just for NS patch browser)
Thanks. That worked. It took about two minutes to rescan the database. What do you think? Retitle the thread as a feature request for automatic detection of new external presets or simply mark it as [SOLVED]?
yeah this is not ideal, to refresh always whole db just because of single preset change..
In other hosts you browse just patches of single plugin - so that host can afford to ask plugin everytime you try open it (or beowse patches) for actual list of presets..
NS is doimg currently this reload only when new plugin is added or if you do it manually (but for all
plugins)
NS patch browser is paying price for it's greatness :-) If you open AU patch browser in NS, notice that on right side above all plugins is "All" - if this is selected, you see presets from ALL plugins on right side
Which is handy in some cases, but it means that NS, to have this list always actualised, would have to recheck ALL plugins.
No idea how to solve this wihout removimg "All"
option which would be a pity.
Idea was that you can immediately start browse patches without choosing particular plugin.
Maybe solution would be to allow manual refresh just for single plugin by adding "reload patch list" option into right hanburger menu when you have plugin selected ?
I think this would be less painfull solution for Matt.
No idea if something like "automatic detection"
of new presers exist, based on my knowledge, it is simply about hist re-asking plugin to deliver again while list of all it's presers
but i may be wrong. This is boundar where my knowledge ends :-)
@toneman that wih iVSC is different problem, thst is out of scooe of NS, iVSC simply doesn't report preset list to host app
Humm. Yes, I see. I wonder if it would be practical to simply rescan that one plugin when it’s selected in the list on the left. Other hosts seem to be able to do it quickly enough to not be noticeable. If not, then yes, manual refresh on request for a single plugin.
Maybe.. i think we leave this on Matt, i don't want speculate here cause i have really no idea what possible solutions are available for this problem ...
Anyway, for now just global refresh
I can live with that.
Good idea,
and "per plugin" added to title would be even more self-explanary
@dendy said:
That pre-supposes a particular solution. A better one may be proposed.
This method is by design to minimize CPU demand via regular scanning of apps. Perhaps there are other ways, but the 'Refresh' function seems pretty quick and easy. Since there is a simple way of handling this (once the procedure is known)
do we really want an alternative to this as a Feature Request? Matt may be making a list and checking it twice, but if we make the list too long it may well be many Christmases before we see any of it. The stated goals will keep him thoroughly busy for most of 2019. I think this thread ought to be marked (Resolved) and the FR dropped so as not to overload Santa. Anyone else agree, or is this a much bigger issue than I realize.
No, I do not agree. Feature requests should NOT be filtered and no one should set themself up as an arbiter of them, nor request consensus to do so. Matt is a big boy and perfectly able to prioritize or reject on his own. You sound like some helicopter parent hovering over at their precious little boy to protect him.
Get the requests out there while they’re fresh on someone’s mind. They’ll drift to the bottom of the pile naturally if not as important as other things.
When I make a feature request, many times it’s not because I care about something. I’m very willing to work around anything. When I make one its mainly 1) because it makes the app look inferior to others and may put off new users, and 2) to avoid people not being able to figure things out, getting frustrated, asking the same questions over and over again, etc.
So, no, I’m not gonna change the title. You guys can mod it if you wanna go there.
I discovered that the preset rescan hosed the settings of the only other AU I had in the project. It set it back to the default preset (not just the name, but all the settings, this was a BASSalicious track. This wasn’t the ReSlice AU I referred to earlier as having the missing preset. BASSalicious appears to be one of the plugins that doesn’t report its presets. Perhaps that has something to do with it. But, a rescan shouldn’t cause existing plugins in a project to lose their settings
Will do some more investigation ...
@SlapHappy i think @number37 is right here.. it is well specified feature request, now we need just leave it on Matt when, how and if he decide to solve this somehow.., yefresh whole DB always just to see songle new user preset in some plugin is far away from beign user frienly and that was always Matts high prio
Fact that there is this request doen't mean any stress for Matt, this is nothing urgent. Just is good to know that there is one particular case with AU preset handling which will be good rethink some day in future... Also for other users is good to know this is something which was discussed.
wait.. if correctly undersrand, you had Bassalicious in oroject and after you did patches database reload, it changes your Bassalocious preset in that project ?
If yes this is definetly bug and should be reported sepaeately. This should definitely not happend, patch database refresh should not affect in aly way instrumenrs loaded in project
It didn’t exactly change the preset. All the settings were set back to the app’s init state. A new user preset called Preset 0 was created in the patch database, listed as the one and only Factory preset.
This one should be dug into further before bug reporting. A better description, how to reproduce, and whether or not it happens with other plugins is needed. I’ll dig further when I’m able.
ok thanks
Fair enough. I can express an opinion and so can you. It's all good. For the record, I am not saying no FR. I just think that there are a lot of more important FR that I would like to see implemented, and re-working existing features should be at the bottom of concern. That's just my personal opinion. Nothing intended to slam anyone.
"You sound like some helicopter parent hovering over at their precious little boy to protect him."
I think that is a bit much. But a lot less painful that the responses you've given me on the AB forum, so... thanks?