Owl Plug App Feedback #118
Replies: 13 comments
-
|
if this is unwanted feedback or the wrong place, feel free to close and THANK you for working on this cool project |
Beta Was this translation helpful? Give feedback.
-
|
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 1. Configure Folder OutputI 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-processI 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 ... 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
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
🗀32You'd then, after extraction, run a process that would leave the readmes and things in the 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 libsI 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: depending on whether or not you've enabled manufacturere grouping (ala item #1) 4. Aggregate DataI 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. 5. Sanitize FeedsEndpoint 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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
@DropSnorz I went ahead and made an issue here: #54 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! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this awesome feedback! 🔥
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
Discussed in another issue.
I really like this idea for better filtering. 🙂
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.
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.
You implemented it! Thanks again for your contribution.
Thank you for sharing this code! We can always implement something similar in Java.
By "sample" are you referencing "demo samples" or plugin "presets"?
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.
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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I've been working on this script pretty steadily and have been using it a lot this last week: Please feel free to look over the source, or pull it down and try it! If you do
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: 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 Owlplug looks at the For instance, here is a plugin you might recognize: Then you run the script, which I am currently keeping in my utility directory as I work on it: if I delete the Dropsnorez folder in the 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 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 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! |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @the-simian, I hope you're doing well! 🙂 I've implemented some data aggregation on the directory UI to view file size consumption. Combined with the manufacturer install toggle you've implemented, you can display metrics "by manufacturer directory". This feature is available on the latest OwlPlug 1.24.0 release.
|
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions