@virango, @OneEng1 and anybody who would contribute to the community editor/librarian - I just thought, before you start working on it, it would be nice to ask community about graphical interface/UI and layout, like ckemper asked about Remote's size and layout.
I stress this because resembling Profiler's interface 1:1 with many pages for parameters doesn't make sense, since having all parameters on one page is desired state by many I think. 23" LCD screen will allow for that for sure.
I always tell my engineers that you first have to establish the "what" you are doing before you start discussing the "how"
There are power point templates that can be used to create UI stuff with. If a few of you have some ideas of what a good UI might look like, put together some sketches and some work-flows as a starting point.
I agree that using the UI of the existing Kemper isn't the best approach for a PC program.
In general, the advantage of a PC program is the huge amount of screen real estate. Using it most effectively is an art.
Another point that everyone could work on would be to put together a list of uses for the editor. These are typically called "use cases". An example would be "The ability to adjust the PEQ using a graphical interface showing the eq curve".
Once a good set of use cases can be established, and a general work flow can be agreed on, then we start the process of prioritizing which features get implemented first. Keep in mind that the main architecture has to be designed before the very first feature is implemented. The architecture must be designed to handle all use cases .... even if some of the use cases are never implemented. The architecture should never be the reason a use case is not completed
Generally speaking the act of sending MIDI commands back and fourth is the easy portion of the program. The difficult part is the work flow and back end architecture IME.