That’s the plan! Batch and Single preset updating.
Sorting them might be technically challenging, but I’ll see what I can do.
1 Like
So far looks good as a prototype UI 
I’d only suggest to maybe use less saturated purple colour for separating lines (maybe use gray and leave purple for when it’s selected - it should look much better 
)
I was thinking and there are few questions appearing in my head related to how it’ll work and what potential issues can and probably will occur & how we can prevent them:
-
How do you want prefixes to work?
This pops up as first question, since prefix would be put to a preset name field therefore the editor won’t be able to read it back into prefix field. You could also potentially double the prefix while mass editing and selecting already edited entries. Of course we can live with it since the tool has to be simple, but this is the issue that will appear. If we decide to fix it by making program read first word before space as prefix, it would work but then it would also introduce the issue in case of presets that contain more words too and didn’t have prefix set before. That’s trickier thing. We could introduce some sign showing it’s end of prefix, e.g.: “LD_Dreamy Sundown” but I personally enjoy prefixes to be without underscore, so like e.g.: “LD Dreamy Sundown” (it also looks more clean).
With names of prefixes themselves, what if we had a list to pick from instead of textbox to type in? That list could be defined in some settings of this program and stored in ini/json/settings file & it would really make it easy to use - user will not have to remember their prefixes they use, and as we all know, we all do mistakes and even if we try to stay consistent we sometimes introduce a mess there. A configurable list with predefined prefixes could solve this potential problem. -
What about style types and how do you want them to work?
This is the second one that I think is also important to be asked (btw I can’t see the field for that entry on your screenshot) because it’ll be cool to - as mentioned with prefixes before - use custom ones but maybe giving people list that they can pick from with ability to add custom ones instead of giving just text field would be more comfy & more prone to issues. Of course personally I’ll be happy even with just simple text field so it’s not a biggie but it could really improve the end user experience a lot. -
How input fields are going to work in relation to mass editing?
Silly but kinda important question - what will happen if I want to massively clean description of all presets VS what if I just don’t want to update descriptions of selected presets? In this simple example we run into an issue that should be solved in some way or another. It applies to Name field too (Author one can be ignored because in most cases it will be always the same person… unless someone edits presets made by others then the same issue happens). To avoid it we can simply make editor ignore field when there’s no character in it. If user wants to just clean the field massively (let’s say it’s that description we want to clean) they can just type space in mentioned field.
Anyway forgive me for so long wall of text (I tried to edit it in a way to make it as painless to read as possible 
), these are just thoughts that don’t need to define where the editor has to go or aim since every user will have own suggestions & idea on how it should be working, but I think & hope these questions can help define how things can work in most comfortable way & point out potential problems you can run into while working on it. ^.^
Good luck and keep me updated! 
1 Like
For prefixes, I have a system that will look and see if there is an underscore before the name and It will separate it:
I haven’t implemented removing it from the Name yet.
For people who want to have a space instead of an underscore, there will be a checkbox.
I might also add in a entry box where you can enter your custom separation character, which would remove the need for a checkbox.
For style types, I just forgot to add in the field lol. I also plan to let users create and save custom styles, as well as prefixes, to a json file which can be accessed by by a dropdown menu on the side. The json will come with the defaults prelisted.
For Input fields, it will apply the changes to every selected preset. I will add in checkboxes to the side of each entry if you want to exclude it from mass editing. I also plan on adding a smaller chart view to let you select individual presets from your selection to edit.
Unfortunately with all this stuff, it’s going to take several weeks to finish this and give it a fluid workflow. I appreciate the feedback!
1 Like
Sounds good! And yeah, there’s more things to be implemented than it looked like at beginning (as always with anything in programming 
) so again good luck with everything and I’m looking forward to it!
Things added:
- You now select the presets from the ‘Preset’ table which gets it’s data from the selected presets in the larger table to the left of it.
- A dropdown menu for prefix and style that will give you a list of things to choose from, as well as a save icon for saving the currently used prefix/style. TBA: a way to save/delete styles and prefixes.
- Checkboxes for selecting values to change when ‘APPLY TO SELECTED’ is pressed. TBA: Setting the defaults to prefix and style checked.
- Changed the color of the tables and added a darker box around the data editing area
- Added Vital tools icon
Nothing is functional yet lol
1 Like
Unless anyone has any suggestions, this will likely be the final GUI layout:
Clicking the edit icon(
) will open up a subscreen to edit you custom prefixes and styles:
Things added:
- An edit icon to open a new menu for editing custom prefixes and styles. Saves to a file.
- A view button that launches vital with the currently selected preset loaded.
- A custom break character, use two apostrophes for white space: (’’) not (") <- this is likely to change
- An exit button in lower right corner.
Things to add:
- Auto updating the prefix/style dropdowns after they are edited in the second window.
- Actual functionality.
As said before, this should be the final GUI layout. Once I figure out how to update the dropdowns, all that’s left is to get actual functionality. Depending on how much school work I have, this should be functional, finished, and released by the end of the week.
2 Likes
Looks really good to me!
Thank you for updating me about this project!
I only have few questions, why are there 2 menus for presets (left and right one)? What is the purpose of the 2nd one? I think you should limit yourself to using only one for this (if 2nd one is just to select single presets then the left table has that ability too).
Other than that it probably looks okay, hard to tell until tested. I only worry about it containing a lot of things on screen which can look bit tricky to understand.
You could probably replace the checkboxes next to fields with just a simple code that checks if field contains string, if it’s null then it doesn’t update the field - that way you will be able to get rid of some elements from UI that introduce some “noise” to it’s readability.
Does the “view” button open preset? Sounds like cool thing to have ^.^
I like that there are separate submenus for definitions of prefixes and styles.
1 Like
The second submenu is used to select within the selection of the first menu. I did this because when you’re selecting things, it can get really spaced out and hard to manage. This system makes it easier by condensing your selection, sort of like a puedo sort feature.
It might be easier to demonstrate in a video, but this workflow is much easier than what I had before, especially when working with a large amount of presets.
And for the checkboxes, when you click on a preset, the info is automatically sent to the edit boxes. So if I was checking for a string, that would get really hard and confusing really fast.
I’ll post a video of the UI in action later and hopefully a lot of things will be easier to see/understand.
You might want to check my previous update as well: Easy basic Vital data editor, taking requests!
2 Likes
I like what you’re doing and it will be a great addition to patch management in Vital.
The Patch Saving system in Omnisphere is a good model for what I’d like in Vital, but extra fields and sorting options will give us a much better workflow with the instrument.
No specific suggestions. I think you’re on the right track and know what’s needed.
P.S. I do have request. Not sure if it’s part of what you’re trying to accomplish. Is an Audion Note possible?
You select a patch and a note is played (the note and its velocity should be able to be set).
Thanks.
That explains a lot, thanks for the answer
I don’t know how that would work, but there is a view button that will launch vital with the currently selected patch.
1 Like
Eat your heart out serum.lol
Ok I swear this is the final GUI update and I am working on functionality now,
Things added:
- Selection options for the 2nd table, + a changed the view icon to an eye.
- Actual Functionality for the save icon
- A replace option that will determine if prefixes are replace what is already there, or append it to the start of the name
- Warnings that pop up when you press any save button related to custom styles and prefixes, basically telling you to reload the program to see the changes in effect. I TRIED TO GET THE MENUS TO UPDATE, but I couldn’t figure it out.
Things Planned:
- Functionality
- Help/About tab
- A backup file that contains the unaltered info data + a button to restore from this file
- Preferences
If everything goes smoothly, this should be out before Monday. If it doesn’t go so smoothly, next week should be enough time.
1 Like
Ok there is still a ton of stuff left to do, and things aren’t going smoothly. Expect this to be out next week, sorry 
2 Likes
Take your time and don’t worry even if it takes a month or two - dev stuff can be tricky sometimes ^.^
Best of luck!
2 Likes
absolutely agree there. rushing will just lead to more bugs to squash later…
1 Like
I HAVE A NEW PLAN
I’m going to recode everything 
Why?
- There are several QoL Changes that I would like to implement that wont work with the current code structure,
- I now have a complete idea of what I want to do so I can create a more planned out UI,
- The code will, hopefully, be more organized and optimized.
- File structure will be much better, especially with image and user preference management.
BUT DONT WORRY
I will be completing the current code that is being worked on and release it as a beta version! This way I can get feedback on how easy it was to use, along with getting notified on some of the bugs found, while developing a more final and polished version.
I’d also like to move this project discussion to discord: https://discord.gg/Jqg7KZsCam
I’ll post more frequent updates on what is being worked on and you can report your bugs and give your feedback here!
The beta will likely be out by the end of the week, but who knows :\
1 Like