Owl Plug App Feedback

[the-simian]

I love the idea of this application and I want to help make it better, so I've compiled some more things that I think will greatly improve the application:
If this is the wrong place to post this let me know
First, if you didn't see, I posted 5 things I think that are very important, and that post is here: #51 (comment)

Here's the feedback in no particular order (and recently edited to include a bit more detail)

• Mark which Items have already been installed in the UI. The waveform vs 'effect' icon is really nice, maybe on the other side of the title, put like a check or change the background of the title. Something obvious.

• The 'mortar' effect is visually interesting and fun, but it's actually really difficult to navigate in most situations. A standard listview or card-view would actually be better. You can certainly do all of the above, and I am not underestimating the visual interest of this being a dashboard/lander layout. The ability to toggle views would be most practical. Think about the NI installer or Steam. The list can just be tabular, with more information and another view can be cards that scroll side-to-side in groups by topic. Think about like how Netflix has 'cards' for 'horror' why not 'cards' for "subtractive" or "chiptunes". As for a tabular view, just go for a canonical high-utility table with sortable columns and a clean pager. I feel like working on this matters a lot. You have the data and the ability to group things effectively, and the presentation of it could take this app to the next level.

• You need to allow the end-user to filter by things already installed. This is very important.

• Make the 'user', 'type', and 'tags' interactive on the right-hand side. If you click one it adds it to the multi-search input. So if I click 'Socalabs' it is as if I had typed it in the search.

• A better pager control than "load more". Something with numbers, and the ability to move in a canonical way. I feel like the UI is designed more like a 'feed' than a thing you can truly search, sort, and navigate. In my own work most user feedback in any situation excluding a 'scrolling feed' has been considered undesirable after earnest A/B testing. In a feed, you want to auto-load like twitter (and also scroll virtually so there's not a performance penalty for long sessions). For nearly any other situation with canonical records management (which I feel like this certainly fits that from an engineering perspective), a traditional pager is very much desired. There is a plentitude of these on the internet, in various js frameworks but here's a common enough example: https://material-ui.com/components/data-grid/
  Edit: I can see you are using JFoenix: http://www.jfoenix.com/documentation.html#TreeTableView would be the right tool I believe

• I still am not clear on what 'Native Discovery' really does, can you put a tooltip or something that clearly expresses what that is? It sounds like you're somehow introspecting the VSTs for more tag information, because it is an option for already installed items, but I'm not sure how that could work. It was difficult enough for me to solve the problem of what arch platform a plugin was (32 v 64 bit). I could not figure out a way to get the manufacturer (which I really would like to manage my stuff). What's really happening here?

• Can you add descriptions in the Options that explain the difference between the cache and the user data? I suspect that one is just the plugin manifest and another is your credentials for G+.. is that it? I think you need some copy here to really explain which does what. That or have a way to itemize the cached data and the user can pick exactly what, not unlike how browsers or windows does it.

• Can you add more about what the G+ Authentication truly does? You could just add some copy in the G+ account popup that describes what the app will do, and why it needs the permissions it is asking for, which are pretty elevated.

[the-simian]

if this is unwanted feedback or the wrong place, feel free to close and THANK you for working on this cool project

[the-simian]

Here is some additional feedback (originally posted in issue #51), which are 5 more application suggestions, in detail that I think would be useful to consider and these are things I was particularly looking for in a management tool.

1. Configure Folder Output
2. Generate 64 adn 32bit folders as a post-process
3. Specify a differnt location for sample libs
4. Produce aggregate plugin data
5. Sanitize the feeds.

1. Configure Folder Output

I think there's at least some utility in configuring how the plugins are nested and foldered. For instance, it is useful to group plugins by a certain manufacturer in a folder. I don't think this would put additional labor on the manufacturer. for instance, for the OB-Xd it would be nice to have:

🗀discoDSP/
    🗀OB-Xd/
        🗎 thing.dll
        🗀 presets/
             🗎 one.patch
             🗎 two.patch
         🗎 manual.pdf 

Since you already possess the name of the creator, this is just a matter of your file writer, and possibly something you could toggle if you preferred a flat look. Consider that in some editors like Ableton, they more-or-less just straight up preserve the folder shape, so this is a way to really help with organization, a core goal of the program.

2. Generate 64 and 32 bit folders as a post-process

I agree it is hard to detect the 64 bit vs 32-bit binaries! I've actually tried to work on this! I worked on a dll-detector last year to try and approach this. There's a very valid use-case for separating these files. A lot of hosts will bridge them for you (like Fruity Loops) but for others, they simply must be jBridged (or some similar approach) Most people, therefore, do still keep their 32 bit and 64 bit VSTs separate and then at minimum do something like this:

🗀VST/
    🗀64/
    🗀32/
    🗀bridged-32/

Where here, the 🗀bridged-32/ is an output folder after running a bridging utility.
I am saying this after researching this earnestly for some time, I think the inability to do some additional sorting might interfere with some usecases

... as for detecting the DLL its actually possible, I was able to do something like this:

let globby = require("globby");
let fs = require("fs-extra");
let path = require("path");

const VST_DIR = __dirname;
const VST_GLOB = "VST/**/*.dll";

const SCAN_GLOB = path
  .resolve(path.join(VST_DIR, VST_GLOB))
  .replace(/\\/g, "/");

function getArchInformation(result) {
  var index = result.indexOf("PE");
  var archIdentifier = result[index + 4].toString(16).toLowerCase();
  switch (archIdentifier) {
    case "4c":
      return "32-bit";
    case "64":
      return "64-bit";
  }
  return "unknown";
}

let listFiles = async () => {
  let files = await globby(SCAN_GLOB);
  let tableInfo = files.map(async (f, i) => {
    let result = await fs.readFile(f);
    let r = {
      name: path.basename(f),
      architecture: getArchInformation(result),
    };
    return r;
  });

  Promise.all(tableInfo).then((plugins) => {
    console.table(plugins);
  });
};

listFiles();

Here is the output:

I've put the code in a repo here if you want to check it out: https://github.com/simiancraft/dll-detector

I apologise if JavaScript is not the best language ever, I was actually earnestly working on some scripts to manage my own vsts before discovering this, project.

I know this doesn't address all the issues, like

• What if a manufacturer puts everything in one folder?
• How do you read and correctly disect that folder apart?

Currently: I am thinking it might be useful to make a post-process that could be run so you'd have like:

🗀VST
  🗀ALL
  🗀64
  🗀32

You'd then, after extraction, run a process that would leave the readmes and things in the 🗀ALL loction and separate the dlls into the 62/32 folders. So you'd only 'copy' the dll. The idea being that you could still keep shared presets in 🗀ALL (or "source?" something like that) and keep it up to date but your editor could look in the right folder or your jbridger could too. You'd dump symlinks for subfolders in the 🗀64 and 🗀32 leading to the respective preset folders, but not taking up additional space.

What do you think of that? I am imagining an option that does this in the settings, like "generate separate 32 and 64 bit folders" or something. I think that's more realistic. This way the manufacturers could still painting existing packaging, and you even leave it like it is, but you'd generate a couple of small folders in a post-process step. After recently reinstalling every plugin in my own studio I can assure you that most paid installers do currently differentiate the 32 and 64 bit locations (as well as AAX). I think more can be done here

3. Specify a differnt location for sample libs

I think you need to also allow manufacture to opt into the ability to specify a separate output for the 'samples/etc' or something of that nature. I think you'd also run this as a post-process step after the .zip extraction. Basically if you, as an Owl Plug user, specify another location where you'd like to actually keep sound-sets/samples etc. this would be the expected program behavior:
1. OwlPlugit downloads and extracts as per usual.
2. If the JSON from the manufacturer indicates that within the .zip there was a soundset, it needs to specify an optional folder name. I am earnestly proposing another optional property under the products section of the JSON schema.
3. As the enduer in my settings I've indicated that the place I keep samples is on another place or another drive such as G:/samples (whereas lets assume C:/VST is where I keep the .dlls)
4. Lets say the manufacture has therefore specified that /SAMPLESET is, indeed the sample-set/assets folder. A as a post-process, after extracting the zip file, move the /SAMPLESET contents, specified in the schema from either
- C:/VST/plugin-name/SAMPLESET to G:/samples/plugin-name/SAMPLESET
OR from
- C:/VST/plugin-name/manufacturer/SAMPLESET to
G:/samples/plugin-name/manufacturer/SAMPLESET,

depending on whether or not you've enabled manufacturere grouping (ala item #1)
5. Finally throw in a symlink in the initial folder so the plugin 'sees' the final destination and behaves normally.

4. Aggregate Data

I think you need to produce meaningful aggregate data on the plugins page, or make a seperate dashboard tab. The ability to select a plugin and see its details is very cool! I am suggesting something like a piegraph of the plugins and their size on disk, or samples on disk. Assuming you take my suggestion in item #1 - break it down by the manufacturer.
I am imagining something with this sort of vibe:

5. Sanitize Feeds

Endpoint validation. Basically, this issue could have likely been fixed before it started if there was some sort of endpoint or schema validation on the feed by the program. It might also be meaningful to have the folks submitting their feeds to also submit them to some sort of endpoint validator? In Javascript, we use tools like joi.js to enforce schema validation at runtime, or you could use a tool like https://docs.frisbyjs.com/ in order to periodically call the endpoint that was registered an enforce that the feed cannot create any aberrant behavior in the application. This is nice for the manufacturers too because they can do some initial checks to make sure their feed is 'sanitary'. Before they put it out in the world.

Thoughts:

In short, those are my 5 big things, and I think that in order to do most of it you'll need to include some sort of reasonable installation post-processor, probably a chain of responsibility sort of thing so you can extend the behavior and keep it orderly. This is the sort of thing that attracted me to this project initially, is dealing with the physical cost of samples vs the dlls, the sprawl of many VSTs across the disk, the ability to truly organize them based on a projection of the data, so my DAW sees them in a meaningful way.

As for the 'chain of responsibility' I would 100% make sure that item #5 is in that chain early on and you're logging bugs or making a file or something so people can submit issues easily. Even better, email the manufacturer of the feed or something like that If it crosses a threshold. Really anything to keep the data more stable and sanitary is good as more stores come into play will make this have higher adoption by both plugin creators and users alike.

[the-simian]

@DropSnorz here's all my feedback in a single ticket after using the tool. I am still using it and I believe this can be something really special. I have earnestly considered building a similar sort of utility in electron.js (tbh this would be very useful for the UI layer), so I am so happy there's already major work on this. I can write some Java, and I am willing to help with some features. I am especially interested in the folder-management and post-processing thing I've mentioned. if you're not opposed I can actually contribute some of this as a command line or js process that is initiated by the app as a prototype before it's canonized in the Java layer. Does that seem useful to you? let me know what I can do to help. I'm already doing some of this work just to manage my own ecosystem.

[the-simian]

@DropSnorz I am working on a PR now for the manufacturer toggle. I have the UI worked out. I was thinking I could open a separate issue and then make a PR against that, is that ok with you?

My work so far is here: https://github.com/simiancraft/OwlPlug/tree/add-store-by-maker-toggle

[the-simian]

@DropSnorz I went ahead and made an issue here: #54
and opened a PR here: #55

I figured if I really wanted to see a feature like this I should be proactive and try to help build it. If you're happy with this I am more than willing to help with more features. This was a good, simple one to get me used to the codebase and how it is organized. Thank you again for this cool project and I hope this code is useful. I've been using it this evening on my local branch and it's been doing exactly what I need!

I have built some scripts that generate the symlinks like I was describing upthread, I also saw you had come code related to symlinks. Are you interested in that post-processing work? I made it in node, but It's following the pattern I outlined in feedback item 2, where I have one 'source of truth' but I generate symlinks in a 64 and 32 folder, so I can bridge the 32 into the 64, and have all 64-bit plugins. Is this interesting or useful to you? I could make an issue just for that discussion, about behavior and show you what I have and what the workflow is. I think this could be a way to help with folks that are dealing with bridging.

Again thank you, and i'd love to know your thoughts. I am sure you can tell I'm excited to help!

[DropSnorz]

Thank you for this awesome feedback! 🔥

Mark which Items have already been installed in the UI. The waveform vs 'effect' icon is really nice, maybe on the other side of the title, put like a check or change the background of the title. Something obvious.

You need to allow the end-user to filter by things already installed. This is very important.

It's a complicated feature in practice. We can add the checkmark just after an installation using OwlPlug but if the plugin is deleted or installed manually it will become quickly outdated. I've already tried the reverse feature: "Detects plugins updates if a most recent version is available somewhere in the "Store" tab." It's working by matching plugins UID detected with Native discovery scan. The technicalUID field must be filled on the store side.

The 'mortar' effect is visually interesting and fun, but it's actually really difficult to navigate in most situations...

A better pager control than "load more". Something with numbers, and the ability to move in a canonical way...

Discussed in another issue.

Make the 'user', 'type', and 'tags' interactive on the right-hand side. If you click one it adds it to the multi-search input. So if I click 'Socalabs' it is as if I had typed it in the search.

I really like this idea for better filtering. 🙂

I still am not clear on what 'Native Discovery' really does...

When native discovery is enabled, plugins are loaded during the scan. Some parts of the plugins are executed to extract metadata filled by developers. (UID, name, manufacturer, version, ...). It's like a DAW, but the UI is not initialized and audio processing is disabled. The JUCE library is used to retrieve metadata values for any plugin type (VST, VST3, AU...). Here is the C++ code used to extract data from plugins.

Can you add descriptions in the Options that explain the difference between the cache and the user data?

• User data is everything configured in OwlPlug (Options, stores, etc...)
• The cache is data stored temporarily by OwlPlug (Mainly plugin screenshots)

Can you add more about what the G+ Authentication truly does? You could just add some copy in the G+ account popup that describes what the app will do, and why it needs the permissions it is asking for, which are pretty elevated.

G+ authentication is a residual feature of an old concept called "Repositories". In the first versions of OwlPlug, there was a feature to sync plugins collection between computers using Google Drive storage. Unfortunately, it was too complicated to maintain and not really stable so I decided to remove it.

1. Configure Folder Output

You implemented it! Thanks again for your contribution.

2. Generate 64 and 32 bit folders as a post-process

Thank you for sharing this code! We can always implement something similar in Java.
It's an interesting feature because 32bit VSTs are still widely used. I'm quite worried about plugins that are relying on the filesystem to load stuff. It seems some plugins can require and load files based on its own installation path. I've received some reports from users who can't load plugins using symlinks because the plugin tries to resolve the installation path to load external files.

3. Specify a differnt location for sample libs

By "sample" are you referencing "demo samples" or plugin "presets"?
For presets, I agree, there might be a complete feature to implement. As it's done for Plugins, Presets can be managed the same way. I imagine some sort of social features where users can submit, share, review, download, and organize community presets.

4. Aggregate Data

It's a really cool idea. Unfortunately, for charts and analytics, I think we are reaching the limits of Java UI capabilities. I've started this project a few years ago when I was at school. I've used Java because it was the solution to quickly set up something... Today, I would do things really differently with different architecture and other technologies. Java is not a bad choice for a Desktop app, but it's not the more maintainable. Alternatives like electron and javascript are very interesting in a lot of points. Better community support, libraries, features, etc... A full rewrite of the app is not planned, but I often think of ways to smoothly transition from Java to Javascript UI.

5. Sanitize feed

There is already a basic schema validation for the store feed. When processed by the app, the Json must match the target Java classes. It's not as strong as validation with the JsonSchema but it handles most problems in the structure.
Every change in OwlPlug Central feed is checked against the schema in a CI pipeline. It's a basic Json schema, and you are right it should probably be more accurate to validate field formats like URLs or enumerations. Error messages during plugin installation should also be more precise. For example by catching non 200 response code during downloads to display something more relevant than the "File not found".

[the-simian]

It's a complicated feature in practice. We can add the checkmark just after an installation using OwlPlug but if the plugin is deleted or installed manually it will become quickly outdated.

You're right. I can VERY easily see how this can get out of sync. My best idea is that we can, at the time of the store updating also test for the presence of the expected folder (based on your output directory configuration and default directory). I am fully aware that this isn't a true installation, as some of the 'installers' are exe's so you might have the folder, but not the .dll or something. The other option, as you say is when you install simply say "you've downloaded this before" or something, Even keeping a short term 'you just downloaded' this check helps, but I see your point: maybe it is better to have nothing?

[the-simian]

Make the 'user', 'type', and 'tags' interactive on the right-hand side. If you click one it adds it to the multi-search input. So if I click 'Socalabs' it is as if I had typed it in the search.

I really like this idea for better filtering. 🙂

Ok this seems really achievable, and a relatively low hanging feature compared to the others, so I am going to open an issue for it. #62

[the-simian]

Can you add more about what the G+ Authentication truly does? You could just add some copy in the G+ account popup that describes what the app will do, and why it needs the permissions it is asking for, which are pretty elevated.

G+ authentication is a residual feature of an old concept called "Repositories". In the first versions of OwlPlug, there was a feature to sync plugins collection between computers using Google Drive storage. Unfortunately, it was too complicated to maintain and not really stable so I decided to remove it.

It sounds like this was an interesting idea, has this feature been totally removed? If not we can put it behind a feature toggle so it does not appear on the frontend. I agree something like this is actually pretty ambitious, and tbh I am thinking the 'truth' should probably be what's locally installed.

That said - I can think of something that might be way easier and not involve so many moving parts. If the ultimate goal is to sync computers or "store" a certain plugin loadout.. maybe it would be better to export a json file that represents the state of your stores and installed plugins. You could then import such a file and just 'install everything' sequentially. This is still a somewhat ambitious feature, but it does cut out a lot of the complexity. You don't need any auth, it is just a flat-file. I do understand this clearly won't work on like, paid plugins and so on, just the ones available over the stores. In this way you could even 'back up' everything and restore, but it would be up to the enduser. You could even share OwlPlug 'loadouts'. Since this would just do two things 1. add any stores you don't have and 2. install plugins one after the other you don't have. This means it wouldn't destroy anything you already have, just be additive.

So that's a compromise I think if you wanted a feature like this.

[the-simian]

Generate 64 and 32 bit folders as a post-process

Thank you for sharing this code! We can always implement something similar in Java.
It's an interesting feature because 32bit VSTs are still widely used. I'm quite worried about plugins that are relying on the filesystem to load stuff. It seems some plugins can require and load files based on its own installation path. I've received some reports from users who can't load plugins using symlinks because the plugin tries to resolve the installation path to load external files.

I've been working on this script pretty steadily and have been using it a lot this last week:

vst-dll-arch-detector

Please feel free to look over the source, or pull it down and try it! If you do

node index.js --dir="../VST" --list

• it will list everything you have, the output looks much nicer than the screenshot

node index.js --dir="../VST" --sortArch

• this will actually make the 32 and 64 directories with symlinks`

I've also added the ability to ignore moving VSTs that have both a 32 and 64 bit, just favoring the 64 bit. The idea being I only want to actually move (and bridge) a plugin if there's NO 64 bit option! I will update the readme to include these additional flags. In the meantime, its a simple script you can see the undocumented switches here:
https://github.com/simiancraft/vst-dll-arch-detector/blob/main/index.js#L12

If we ever had our own 64-bit bridger, we could literally do this entire thing within owlplug!

Right now here's my workflow with it:

I have a folder structure like this:

The /32 and /64 bit plugins are generated entirely...

Owlplug looks at the Core dir, that is ALSO (where I install my paid plugins). I install everything here, sorted by the creator/manufacturer in my own case. I put the presets in here too, (except for native instruments and Waves which insist on being weird).

For instance, here is a plugin you might recognize:

and in the output dir:

This is just a symlink, and I point my DAW at this.

Then you run the script, which I am currently keeping in my utility directory as I work on it:

node index.js --dir='../../Core' --sortArch

if I delete the Dropsnorez folder in the /64 dir and run the small app...

it skips things already linked, and creates the symlink. since you have both a 32 and 64 bit version you distribute, higher up in the list you see this:

Because by default I am willfully skipping things that I think I might have a 32 bit match for, this is not moved or symlinked. I really just only need the 64 bit.

For everything that ultimately DID get moved into the 32 bit I can assume there's no 64 bit dll at all. So for these, I can run jbridge (or anything ) and these get bridged into the 32_to_64_bridged dir. I haven't managed to run jbridge on the cmd line, nor found an OSS one, or I would just do this all in a single step, tbh.

Then you run the plugin a second time like node index.js --dir='../../32_to_64_bridged' --sortArch. This now puts the new 64 bit plugins (freshly bridged) as symlinks in the 64 bit dir. So now the 64 bit dir is a bunch of symlinks of only 64 bit and 32 bit bridged items.

It works pretty well!

So I am thinking, what if we also made generated dirs of symlinks based on tags? Since we introspect everything, there's such an amazing ability to just make folders with things already organized! For me even having them sorted by creator is huge, and really helps me a lot, but what if there was also /drum-machines and so on? They're just symlinks so very small. My entire 64-bit dir of every plugin (I have over 200 atm) is only a mere 2.47kb. So duplication of plugins across 'taxonomy folders' is not a big deal. This also means you can just point any DAW (all which are very good at symlink reading) to your folders and you're insta-organized via a build step rather than manually doing a bespoke system per DAW. This is what ti'd like to work towards. If I can even export the metadata owlpluig makes I can use THAT with this tool and make progress!

So maybe that's a first step? exporting the scanned metadata as a flat .json file? if we have that I can make all the directories, and prototype them in node. I am very enthusiastic about this feature!

[the-simian]

Specify a differnt location for sample libs

By "sample" are you referencing "demo samples" or plugin "presets"?
For presets, I agree, there might be a complete feature to implement. As it's done for Plugins, Presets can be managed the same way. I imagine some sort of social features where users can submit, share, review, download, and organize community presets.

I actually do mean presets, however, presets are usually not explicitly what takes up a lot of space. I was thinking like actual assets that might be bundled with a plugin.. including but not limited to presets. For instance, a wavetable synth might have many wavetable banks, or a drum matching might ship with a /samples directory of many 1-shots. Romplers are in a similar boat. a full-featured rompler might be very large on disk, especially those 'we are recreating the sounds of a such-and-such' somethings its just gigs of samples. Basically, there's a lot of categories of plugins that might some with assets that often people move to another directory. For a real-world example: Native Instruments Battery

[the-simian]

Aggregate Data

It's a really cool idea. Unfortunately, for charts and analytics, I think we are reaching the limits of Java UI capabilities. I've started this project a few years ago when I was at school. I've used Java because it was the solution to quickly set up something... Today, I would do things really differently with different architecture and other technologies. Java is not a bad choice for a Desktop app, but it's not the more maintainable. Alternatives like electron and javascript are very interesting in a lot of points. Better community support, libraries, features, etc... A full rewrite of the app is not planned, but I often think of ways to smoothly transition from Java to Javascript UI.

I happen to be an Electron expert, and I agree Javascript would handle this very well. If you are actually interested in a JS rewrite, tbh the JUCE integration is the part that would give me the most challenge - the UI, by contrast, is relatively straightforward. I am working on another closed source project based in Snowpack, React and Recoil.js.. this stack would do very very well at a project like this. an OwlPlug 2 perhaps? The store JSON is already very good, and it could consume the same API. Just thinking out loud here.