I don't use similar names for folder here anywhere
what are you missing in these 4 points? how it is different from this iTunes?
1) user can create folders and nested folders
2) user can put rigs inside folders and any of nested folders
3) total number of rigs displayed after folder name should count all the rigs inside current folder as well as inside of all nested folders
4) the search scope is current folder and all nested folders (if any)
Yes you did. "Folder" and "nested folder." What you're describing is exactly how RM works now with the exception of the count and the search scope. You can create a folder. You can create a folder under any other folder (a "nested" folder). Right now, I believe there is a 2-level limit, which describes, to the T, exactly what you're discussing.
iTunes, Spotify, and, most importantly, every single computer's file structure does not work exactly like this, and this is why it's confusing. There are three essential parts to this, going from most specific to least specific:
1. Your rig. We all know what the rigs are - a file describing the rig and its settings.
2. A container for a set of rigs, a.k.a. a playlist (and that's what I'll be calling it from here out). In iTunes or Spotify, this works like the following video (a bit outdated but the idea still works):
Music playlist files, by the .m3u or .pls spec, are files that contain a list of songs that exist on your computer. For the .m3u spec and for more information, you can find out more here: https://en.wikipedia.org/wiki/M3U We wouldn't need to use a .m3u file (or multiple) for playlists, because I'm guessing that Rig Manager stores everything in a SQLite database somewhere on your machine, but the concept is the same, regardless of storage medium. For the Kemper, the playlist would be a list of all rigs (instead of, using the iTunes example, songs) that exist in a certain location on your computer.
3. Folders. A folder should contain only playlists or other folders. Think of RM as a closed file system, where these are the only file types allowed. A folder, when clicked, should show the contents of all playlists within the current folder or in subfolders underneath.
But why should we never place rigs directly into folders?
With a playlist, you know the only thing it references are rigs. If you have folders containing rigs, and that folder contains another folder, clicking that parent folder gives you no indication that there is a rig on that main folder (which contains other folders). There is a clear distinction between what does what, what contains what, and how everything is handled.
For instance, in the current method, say you have Local Library/My Saved Rigs containing 3 rigs, and Local Library/My Saved Rigs/MBritt Profile Pack 1 containing 62 rigs. The top level folder (Local Library/My Saved Rigs) would display 65 total rigs. This is fine for simple browsing, but, if I delete the MBritt folder, how do I know what's left before I delete, without going through one-by-one? If I want to move those 3 out to a separate playlist, then I have to compare two lists to find the differences. Now, imagine you have 25 folders, each with a different count of rigs. Good luck finding which 3 rigs are on the top level.
The numbers add up properly when using playlists. For example, if you have 3 playlists with 50 rigs each, each playlist will display 50 next to it and the parent folder will display 150. You can find every rig very simply. Searching becomes much easier, as you click on the folder and search for everything within. Counting becomes simple as well from a coding point of view - find all playlists with this folder as a parent (or ancestor of some sort) and sum the count. You don't have to iterate through folders finding files with specific extensions any longer.
Finally, and, arguably the most important reason for this - by changing this structure, it makes it possible for your "Local Library" to reference rigs that may not exist in a playlist, and your "Local Library" actually becomes more of a complete library view, where everything you have lives there, even when removed from all playlists. Users can then choose how they want to approach their rigs - make tons of folders and be hyper-organized, to just use their "Local Library" and search, or use a hybrid approach - use "Local Library" for most things, and the most common things can be broken out into folders. "Local Library" basically becomes your complete local rig library, where, similarly in iTunes, the "Music" top level item is your complete local music library.
TL;DR:
- [ Local Library ] (1545) - clicking here displays all rigs, including the 10 missing from the playlists below)
- > Folder (100) (the only thing that exists in this folder are two playlists:)
- Rig Pack 1 (60)
- Rig Pack 2 (40)
- > Folder (94) (the only thing that exists in this folder are two playlists:)
- Rig Pack 3 (14)
- Rig Pack 4 (80)
- To Sort - Rig Pack 5 (1241)
- > Folder (100) (the only thing that exists in this folder are two playlists:)