elmquist wrote:First of all thanks a lot for you taking the lead on the Linux port of the QuNeo editor, jrussel! I am looking forward to use it though I will use a source code distribution and possibly try to see if I can run it on QT5.1 as that is where my focus is anyway.
There will be a little work to make it go on QT5, but I suspect not much. My main reasons for staying focused on QT4 are two: KMI is using 4.0 for the official builds, so I didnt want to force them to change yet, and QT5 is not generally available as part of most distributions currently. So, for me, there was no real gain.
That said I heartily encourage experimentation in this direction!
elmquist wrote:
It does take time to build an open source project so please do not expect wonders when releasing the source code. There may be a slow start and not everyone may want to run early binary releases when the source code will be available soon.
I recognize it will take time to build the open source project, especially as it is not yet open source! However, my first focus is keeping Linux interest - the community was clamoring for Linux support.. we are getting it.. we need to show we appreciate it!
There are plenty of Linux users that dont want to build from source.. I am more concerned that THEY get on board and start using the binary offerings and enjoying their QuNeos!
elmquist wrote:
What license will the editor be released under?
The KMI team will have to answer this.
elmquist wrote:
Is qmake being used to build the editor?
Yes. I may build a CMake build at some point, to ease cross-compilations, but for now just using the QMake build that KMI provided.
elmquist wrote:
As for the types of access to the device I am only used to work with the exclusive access to MIDI devices and that is plenty for me. But I can surely see the advantage of being able to configure and test the device without having to constantly start and stop the programs (as long as preset updates work in shared mode).
Which one should be the default? Well given that the first thing people has to do is upgrading their firmware the exclusive access seems to be the right default. Otherwise people have to make special actions before they can upgrade the firmware - and that will be quite a noise generator!
Should the shared mode be selectable as a command line option or as a setting inside the GUI? Possibly both! No matter where it will be placed users have to be aware of the option of shared access and they have to be able to find it easily.
Well, you may have misunderstood the questions here a bit. Access for everything except firmware update will be shared - its what I put in, what I would use, and IMHO the most useful way. I know that it will aggrevate Windows users because I cant give the same to them - but that is a Windows limitation, not the editor.
You are right, the first thing someone has to do with a new version of the editor/firmware is update the firmware.. but that is a ONE TIME thing, so I would rather focus on making the 80% case the best experience of all. My intent would be to "down shift" to exclusive mode for updates, with automatic "up shift" back to preset edit / shared mode.
elmquist wrote:
Have you considered how the editor should find its runtime files? The easy way is to require them to be in the same directory as the application is started from. Another is to hard code the path to the files inside the binary. Quite a few Unix applications does so. And finally there is the option of having the application to search for itself using the name its called as together with the PATH environment variable and derive the location of the runtime files from that. As long as the editor is a source code distribution I think that the hard coded path will work best though perhaps with a command line option to override the default value.
For the alphas, and probably any betas I create, the runtime files (just 2 preset files, the running and the factory) will be in fixed relative locations - again, because this is how the editor was written to start with.
When we start creating .deb/.rpm packages, I would probably want to move the factory preset file to /usr/share/quneo_editor, and store the QuNeo.json (your current presets) in ~/.kmi/quneo_1.x.x
In fact, I think I will put that on my list of things to do - not requre there to be a QuNeo.json file available before starting, but rather create it in the appropriate location on startup from the factory file, with a second task of making ask you if you want to import/upgrade a previous version..