Firmware upgrade with Linux?

jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

Re: Firmware upgrade with Linux?

Postby jrussell » Fri Jul 26, 2013 5:43 pm

@TheSupport: I am putting concise instructions on how to perform firmware updates on the qnTools Wiki - is it ok to post the link to the "sex_files" there?

I can direct them to this thread for now, but would prefer to save anyone interested from the thread search :)
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

Re: Firmware upgrade with Linux?

Postby jrussell » Sat Jul 27, 2013 1:06 am

Ok, documentation of the 1.2.x firmware SysEx format is all updated and pretty complete.

Did a lot of clean up, updated some missing labels, added notes for special values where I knew them.

There are a 4 unlabeled properties.. if someone can shed light on what they are, please do and I will update the docs.

Docs at
https://bitbucket.org/jrussellsmyth/qnt ... x%20Format

These docs also reference the locations in the KMI Json files, so it can serve as a bit of a reference for understanding the JSON as well.
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Sat Jul 27, 2013 4:03 pm

Awesome work jrussell! I suspect linking to the sex_files is okay, provided you mean the ones I think you mean.:)

Good points about the popularity of the thread and the reasonability of opening up the editor, thanks for putting those together. It's been a little while since we last discussed it, and now seems like a good time to bring it up again internally. I wouldn't be surprised if it could happen once they're happy with the codebase, and I would certainly be excited to see more people doing original programming for the QuNeo. I'll forward the most recent posts on and see if I can get any momentum going.
User avatar
jscott
Posts: 42
Joined: Thu Nov 08, 2012 2:52 pm

Re: Firmware upgrade with Linux?

Postby jscott » Sat Jul 27, 2013 10:10 pm

I'm now confused about the previous claims that the device would be open, ie "QuNeo, 3D Multi-touch Open Source MIDI & USB Pad Controller" as the Kickstarter title read.

Does it just mean now that the sysex format and editor is going to be open?

Documenting the sysex or having an editor is not really what open means. Providing Sysex documentation is an ordinary and normal thing for all MIDI devices. Devices without it are inadequately documented.

My understanding of openness would be that we would be able to reprogram the firmware ourselves. KMI provides the hardware, and if we want to make it work our own way we can do so and have alternative firmwares. Is that the plan but it's just taking a long time or is that never going to happen? Identifying and advertising a hardware device as being open source doesn't really suggest that the open source merely will mean the sysex format, or the editor code. Anyone can write their own editor given the sysex format so that's not particularly meaningful. For example, the Monome is promoted as cc by-nc-na open source, and the firmware code is available and can be rewritten by user to support whatever functions they like, as long as it is non-commercial. There is a whole scene doing alternative operating systems for various devices.
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Sun Jul 28, 2013 3:48 pm

I'm certainly sympathetic to those ideas, although I'm not quite ready to get into an argument about 'if this or that isn't opened, you can't say open source'. Open source comes in a lot of flavors, and I don't think every company should have to see the dichotomy as being either totally closed or being as open as a place like Sparkfun. I am definitely of the generation that feels opening source early and often can be easy and yield a lot of great things - you just make something and throw it out in the wild and see if it takes root and move on. But the older more experienced business people have a greater appreciation for the fact that, in a normal company, every software release creates added maintenance overhead, often significant overhead to do things right. Since resources are finite, they've been focused on making the QuNeo work well out of the box for the majority of people who are never going to hack or change their code, and then to hopefully go back and try to open things up once they're stable.

I'm not totally familiar with all of Monome's practices or if they've opened all of their controllers or not, but the 40h, which I do know, uses an atmel processor which has excellent free compilers, so releasing the code for that is vey easy. With gcc so ubiquitous and and with the free avr compilers being so good, one often forgets that in the rest of the chip world compilers are not always free, many of them are designed and maintained by companies who need to pay their developers. The compiler for the QuNeo firmware costs thousands of dollars which makes the firmware difficult to open up (unless we expect people to pirate the compiler which would be morally shady on our part, or unless somebody were to port the entire program over to a free compiler which might be too much to expect.) An argument could be made for it, maybe a handful of professional firmware programmers might run with it, it could be awesome, maybe...

Anyway, meanwhile the scripts for Ableton have been opened and are, I believe, frequently modified by users. Unfortunately the open source Max Dev Kit ,which cooks raw data from the Quneo, has received a very tepid response so far so it just seemed better for users and for the company for us to be working on other problems that users cared about.

That's why I really appreciate jrussell's post, because it makes a compelling argument that opening more code is a worthwhile use of resources and can generate consistent long term interest and development. I feel it in my gut that opening code is a good thing to do, but in a small company where focusing on the right problems every hour of the work day is crucial to staying afloat and moving forward, we each have to be able to make those compelling arguments for why the thing that we personally think is important is something the company should be doing right now. I think now is an ideal time to raise the possibility of opening up the editor code, I'm hoping to get it some traction.
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Sun Jul 28, 2013 4:58 pm

Sorry, that's kind of a wordy response, and probably not super-satisfying, it would be nicer if it was simpler! Hopefully it will get simpler with time, we're still collectively trying to find the best way to do these things for KMI and for our users, and seeing people use stuff and do things with it is the best kind of feedback.
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

Re: Firmware upgrade with Linux?

Postby jrussell » Mon Jul 29, 2013 9:30 pm

@demcanulty - can you help fill in the information on the following data values that are taken from the JSON and sent in the SYSEX:

RhombusButtons.RhombusButtonX.rhombusInNoteG
RhombusButtons.RhombusButtonX.rhombusInNoteR

Pads.padBankChangeMode
Pads.padOffset

Also the following - their meaning is relatively clear, but as they are not alterable in the KMI editor, there is question as to their functionality? and what the EnableSwitch would be..

ModeButtons.ModeButtonX.modeOutVelocityValue
ModeButtons.ModeButtonX.modeEnableSwitch
ModeButtons.ModeButtonX.modeChannel
ModeButtons.ModeButtonX.modeOutNote
ModeButtons.ModeButtonX.modeOutPress

If we can fill in these bits of info, the sysex docs at qnTools will be pretty complete.
TheSupport@KMI
Posts: 726
Joined: Wed Jul 13, 2011 12:30 pm

Re: Firmware upgrade with Linux?

Postby TheSupport@KMI » Tue Jul 30, 2013 1:20 pm

demcanulty can expand and/or correct me if I'm wrong, but I feel like the mode button stuff is there in case we ever decided to let the mode button be editable and treat it just like any of the other buttons. Not sure how it functions if that stuff gets edited though.
2, 3, 5, 13, 89, 233, 1597, 28657, 514229, 433494437, 2971215073
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Tue Jul 30, 2013 3:38 pm

Had to do a little digging to remember:

Pads.padBankChangeMode changes whether or not a slew of note-offs are sent following a pad bank change. Some controllers do a blanket of offs while other controllers let them hang, this allows you to switch between these two behaviors.

Everything else is vestigal or reserved for future use and doesn't have a specific functionality. On some of our other controllers the sensors all have what we call "Mod lines", which are algorithms to offset and scale sensor input and padOffset is leftover from when we were debating about whether or not to put that in and how to implement it. Ultimately we decided to leave it as just a gain adjustment, but if we want to go back in and add it later it's there.

All the mode button stuff is left from the very beginning when we thought you could maybe use the mode button as a regular button if you wanted, but that turned out to be really confusing and meant you could load up a preset and not get out of it, so we kind of smacked ourselves on the forehead and stripped out all that code.

Those two rhombus button items were put in when we were considering having a few buttons be assigned to variable notes rather than fixed the way they are now. The problem with reassigning leds to different notes is that it involves searching through this massive linked list every time any note comes in, so for efficiency's sake we've kept everything fixed so there's a really efficient method of jumping from the note message directly to the appropriate code for the right led. But anyway, we considered making the rhombus an exception (I can't remember the exact reason) and then later decided against it. Rather than removing these things, I decided to leave them in during the development process to keep things simple, and also since we might someday decide to use them for something and then they'd already be there.
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Thu Aug 01, 2013 10:59 am

Good news! We just got the go ahead to put up the editor source! Our lead programmer says he'll hopefully have it up sometime Monday. For now it's possible we'll just do it here on the forum and then later try to do it more officially.

Return to “QuNeo General Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests

cron