Page 11 of 16

Re: Firmware upgrade with Linux?

Posted: Sat Aug 10, 2013 3:20 pm
by connerlacy
Hi All,

I'm happy to announce the QuNeo Editor source is up on github as a private repository. jrussell has already made some excellent headway on getting a fully functional Linux build going.

If you'd like access to the source, just send me a message with your github account name and I'll add you as a collaborator.

The plan is to make the repo fully public in the near future, and hopefully release the QuNexus Editor code as well.

Looking forward!


tethered mode is good

Posted: Sat Aug 10, 2013 7:34 pm
by jscott
demcanulty wrote:the open source Max Dev Kit ,which cooks raw data from the Quneo, has received a very tepid response so far

OK, thanks very much for that note Dan. I had not fiddled with the Max patch before. I now see that the Tethered Mode which sends raw sensor data is sufficient for prototyping new interactions. If we come up with something cool enough then at that point you could fold it into the firmware if thought appropriate.

I thus retract my call for open firmware at this time since the raw sensor mode seems sufficient to prototype what I want to do. I also look forward enthusiastically to working with the mentioned 14 bit firmware mode.

Re: Firmware upgrade with Linux?

Posted: Sat Aug 10, 2013 11:07 pm
by jrussell
connerlacy wrote:Hi All,
I'm happy to announce the QuNeo Editor source is up on github as a private repository.

For the community, let me publicly thank you and your organization for moving forward with this!

connerlacy wrote: jrussell has already made some excellent headway on getting a fully functional Linux build going.

What is working:
  • GUI fully operational.
  • Presets fully editable.
  • Preset Import and Export.
  • Firmware version detection.
  • Update single or all presets.
  • Audition/revert preset.
  • Swap Pad LEDS
  • Toggle Program Change In
What is not working:
  • Update Firmware - working on issues of ALSA and big SysEx dont play nice.
  • Reset preset/all presets to factory - this is most likely just an issue with my build/packaging
  • Toggle Program Change out - not sure on this one.
Most of this is a credit to Conner and the KMI team. The only REAL work I am doing is on the midi communication part - the GUI work is completely untouched by me.

connerlacy wrote:If you'd like access to the source, just send me a message with your github account name and I'll add you as a collaborator.

Though Connor has given commit access to those of us on the collaborator list, I would suggest for now we work in good open source form, and submit changes as pull requests from private forks. This will help us prevent any issues that could make Connor and his team change their minds about our collaboration by making sure each change is understood and reviewed.

Input Needed for Linux Port

Posted: Sun Aug 11, 2013 9:19 pm
by jrussell
Two choices for Linux port:
  1. Require exclusive access to QuNeo before performing any operation.
    - This would disallow update preset - test - update preset cycle in most cases as it would prevent connecting to any other midi device for testing while editor is running/connected
  2. Use shared access to QuNeo for all non-firmware operations, attempt exclusive access only when updating firmware
    - Makes the editor more useful for general preset editing
    - could result in occasional inability to update firmware even though you were able to update presets.
    - could result in occasionally not being able to update presets after a firmware update.
    - more complicated coding
  3. Dont enable firmware updating from the editor, instead pop a dialog with a link to the manual "amidi" based method.

So the one major issue I am having porting the QuNeo editor to Linux is in updating the QuNeo Firmware. The issue I am having is that the ALSA sequencer subsystem is designed for midi performance data, and as such is not designed to handle massive sysex files such as those used for firmware update. The "fix" is to use the ALSA RAW interface, which will successfully transmit the needed SysEx files (and is the work behind the manual amidi method of sysex update).

The problem with ALSA RAW is that you must be able to gain exclusive access to the midi port in question - nothing else can be using the port, including (but not limited to) the amidid or alsa2jack tools used to make midi ports available to JACK, and the editor itself. There is no (realistic) way for the editor to stop other processes, so it will require user intervention to stop any processes.

So I am left with a choice - one access method or two.

One access method - exclusive port access - would mean the editor itself would always need exclusive access - this would be easier, as there would be no need to switch modes, and would not require "switching back" after a firmware update, but would mean for most people being in a "quneo edit session" disabling a lot of usually connected processes (alsa2jack, etc) even when NOT doing a firmware update.

Two access methods - shared for everything except for firmware, exclusive for firmware - would mean for everything except firmware updates, you just connect and go.. but to do a firmware update, the editor would need to switch gears to exclusive mode (not terribly hard), warn user to disconnect other processes, deal with errors that occur if user did NOT end other processes, do the firmware update, then switch BACK to shared mode.. the switch back may be problematic as there is no way to know when the quneo is DONE updating, plus on the quneo "reboot" it sometimes will get a different address, so there is a possibility that it is not where the editor expects it.

leaving it to the user to use the manual method is of course easy for me :)

So my intent currently is to leave it manual for the first "alpha" builds, so that I can get a usable editor ready, and built in a way that others can test it soon. Then I would take on the second choice, unless someone convinces me that the easier, exclusive only path is better for the users.

Thanks for your input.

Re: Firmware upgrade with Linux?

Posted: Sun Aug 11, 2013 10:29 pm
by jrussell
Update for Linux editor port:
  1. Reset preset to factory and Reset All Presets to factory are working - it was an "installation" issue in my test setup.
  2. Toggle Program Change Out is still not working - but the windows version does not work for me either!
Can anyone confirm or deny the operation of the Toggle Program Change Out function?

What is working:
  • GUI fully operational.
  • Presets fully editable.
  • Preset Import and Export.
  • Firmware version detection.
  • Update single or all presets.
  • Audition/revert preset.
  • Swap Pad LEDS
  • Toggle Program Change In
  • Reset preset/all presets to factory

What is not working:
  • Update Firmware - looking for feedback on best permanent solution.
  • Toggle Program Change out - windows version does not work for me either!

Linux x86_64 Preset Editor ALPHA

Posted: Mon Aug 12, 2013 9:35 pm
by jrussell
Hello All,

Please find attached to this post an ALPHA build of the KMI QuNeo Preset Editor! This build is for 64bit only - x86_64 machines.

To use, unzip the zip which will give you a QuNeo-Editor directory. In this directory is QuNeoEditor - start this from within the QuNeo-Editor directory (this is a requirement!). If you create a short-cut/link for it, make sure to set up the working directory to be the QuNeo-Editor directory. This is a requirement to find the various JSON files necessary for proper operation.

See my previous post for what is/is not working, but briefly everything except for firmware update and toggle program change out should be working.

Currently, just like the windows version, the editor requires that one and only one QuNeo is connected.

You will need 2 dependancies from your distributions packaging system - asound, which should be installed already in almost any case, and Qt4, which most will also already have installed.

PLEASE report any issues with this build on this thread.

I will work to get a 32 bit build asap, and some time soon a .deb

Re: Firmware upgrade with Linux?

Posted: Wed Aug 14, 2013 10:26 am
by jrussell
Attached please find a 32 bit linux build of the QuNeo Preset Editor.

I forgot the disclaimer with the last one..


Please Try the LINUX Editor!

Posted: Thu Aug 15, 2013 7:43 am
by jrussell
Hello to all forum readers!

If you are a Linux user with a QuNeo, please PLEASE download and try the Linux builds of the preset editor, and direct your friends to the announcment post

QuNeo Preset Editor for LINUX!! (Alpha)

It is important that we show KMI that there is indeed Linux, and Open Source, interest in their products, so that we can continue to build this relationship and continue to build Linux support for the products we use!

Even if you just download it, try it once, and report back here success or failure, it will help the software developers to know how things are working, and KMI know there is interest!


Re: Firmware upgrade with Linux?

Posted: Thu Aug 15, 2013 7:14 pm
by jrussell
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..

Re: Firmware upgrade with Linux?

Posted: Mon Sep 02, 2013 3:19 pm
by jrussell
I cant believe not a single report from a Linux user attempting the alphas! I actually feel kind of silly now having posted here how obvious it was that Linux users deserved some KMI love...

Since noone else will report - let me give a little one..

The Preset editor was awesome to have for a quick change I needed to make in my personal setup. My procedure in the past for preset edits was to use the windows editor under WINE, save the presets, and upload with teh qnTools qn_updater. Certianly worked fine, but several extra steps to say the least.

Being able to fire up the editor, make changes, hit audition, try them out, make changes, audition, etc, was really an improvement on the workflow.

I am putting the time in this weekend to try to get the firmware upload working - a real bear since I have to switch to different midi connection methodology to get the big sysex file sent, but it is the only missing piece.