Firmware upgrade with Linux?

demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Fri Dec 21, 2012 12:41 am

I haven't gotten to give this as much attention as I'd like since we're getting 1.2 out before the holidays (a huge thanks to the editor team who have a much more difficult row to hoe than myself, as I just have to get the firmware into shape but they have to get installers and editors compiled for all half a million windows operating systems and one or two dozen mac systems on the side), but a problem cropped up while my colleague, who is working on the QuNexus firmware, was working on getting sysex preset uploading functioning. Apparently my javascript code was turning 10s (or 0x0A) into 13s (or 0x0D). This turned out to be a JSDB problem, not a bug, but a failure on my part to declare that I was opening the .syx file as a binary using the letter 'b'. So, maybe, try replacing my 'w' with 'wb' in the opening of the .syx file. That turned out to fix his problems, and might make my code agree with yours. I'm guessing that it worked well enough at first for me, but with javascript's loose type system, something got screwed up somewhere and more explicitness is more explicit, and thus more likely to be accurate and not screw up your tens (LF: NL line feeds) and your thirteens (CR: carriage returns). I hope that's all the problem is, let me know if that helps at all.
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Fri Dec 21, 2012 12:54 am

Er, not meaning that in the case of the sysex they're LF or CR, but rather that if javascript thinks you're talking ascii, it might screw those up because it might be using some code it shouldn't be to massage your numbers into something nice for some other operating system. So probably it's best to specify binary so outByte doesn't somewhere unseen become outChar.

PS in another thread, I was proposing in January starting a Quneo open source thread to talk about what to make open source and how to best serve people. I'll be, of course, having to work and convince my own management and stuff for big things, but they've been very free with me/us releasing software details about communication specs and what all. I think there's a lot of room for open sourcing, but for all of us it's not clear how much actual users want to mess around with the hard work of low level stuff. I feel this crowd is the most likely that I've come across so far to do real development work, and I'd like to keep working on this kind of collaboration space as much as possible.
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

Re: Firmware upgrade with Linux?

Postby jrussell » Sun Dec 23, 2012 2:56 am

I think there's a lot of room for open sourcing, but for all of us it's not clear how much actual users want to mess around with the hard work of low level stuff.


The OSS world is a funny thing - we will play with anything we get enough information for! Unfortunately, how far we take it or what projects will take off is hard to say until it happens.

I would not be suprised to see some OSS hackers pick up the QuNeo firmware and build alternate versions with different feature sets.. but there is no guarantee that will happen. Only way to know is release enough info / samples / source that the opportunity is there.

For my part, as long as the firmware works, and important features continue to be added (the 1.2 release looks like lots of nice features were added) I probably wont go there, but would enjoy supporting some 3rd party firmware with preset editor/updater functionality.

Any idea when we might hope to see the specs for the 1.2 preset data/sysex? I am going to hold serious preset editor development until this is available, as there are definitely features there I want to be able to use, and I dont expect many will want to hang back on 1.1 once 1.2 is GA.

In the mean time I plan to get my build system worked out and hopefully multi platform builds/packaging, choose a gui toolkit, and get those docs up. Would be glad to participate in any discussions of OSS.

Hey, one question - can we get some official release or license on the provided data so we can protect OSS projects? I mean my project has 0 code from you, in fact looks very little like your js code, but OSS folks like to have assurances there code will stay OSS.
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

License question for all

Postby jrussell » Sun Dec 23, 2012 2:59 am

Anyone on this thread have thoughts about what license to release QuNeo open source software under? Preferences with reasons would be helpfull, as I would like to have some idea what the user community would want to see, and why..

Myself I tend to lean more towards Apache style licensing (very permissive) so I dont lock myself out of future OSS or commercial use of my own code.. but some things GPL heavy is fine and sometimes even makes sense.. but I am not building a world changing core library here, and it is obvious there will be at least one other similar project and I dont want to compete only on license.
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

SysEx Documentation

Postby jrussell » Mon Dec 24, 2012 1:13 am

For those interested, I have begun to document the (v1.1) SysEx messages on the qnTools Wiki
https://bitbucket.org/jrussellsmyth/qntools/wiki/Home

It is rather tedius work, transcribing my notes to something usable, so it may take me a few days, but it is coming.
User avatar
jscott
Posts: 42
Joined: Thu Nov 08, 2012 2:52 pm

Messing around with the Hard Work of Low Level Stuff

Postby jscott » Mon Dec 24, 2012 3:33 am

demcanulty wrote:I was proposing in January starting a Quneo open source thread to talk about what to make open source and how to best serve people. ... I think there's a lot of room for open sourcing, but for all of us it's not clear how much actual users want to mess around with the hard work of low level stuff.


I'm quite glad to have the sysex specs for the patches now. I'll also say that because of the very good decision you guys made to use JSON format, parsing the patch files was trivial and enabled me to do the editing I wanted and still take advantage of the graphical interface without having to reinvent the wheel.

However, the really important work is in fixing the interpretation of sensor data to MIDI data. There's a bunch of issues here, and the only way to work on the problem is access to the firmware dev kit. For example, currently the aftertouch and note on interpretations are not compatible with each other in the way normal aftertouch sensitive instruments work. If you modulate aftertouch at all (z controller) you end up toggling the note on and off. I suspect that I can fix this by placing the full range of the z well above the note release threshhold. There needs to be a big gap there of 0 level z values, so basically something like pressure values 40-128 map to 0-127 pressure and then everything below 40 is a 0 for z axis, without sending duplicate values. But when using a pad with xyz and no note on though the full range should be used, the way it works currently. It's just when the note is added that pressure control stops making sense since this was left out. Having access to the firmware I can experiment with sensor values and probably fix this.

Another issue is the inconsistent pressure response in different parts of the pads. Middle is full range, sides are not. This is likely due to the underlying sensors being round as can be seen in the board photos. But then in the 4-corner mode, it is really weird and seems to not be full range. But the velocity response is OK which means that some effort went into figuring that out for different parts of the pad, but the same attention to the math that compensates the nonlinearity and makes it all consistent and linear again hasn't been given to the pressure interpretation. This one is probably harder to fix.

Then there's also the ability to add features. I am super glad to see a high level added to the pressure control to facilitate the momentary and toggle. But the low value is 0 and can't be edited. It is much better to have both a specifiable low and high per controller. Novation controllers have both low and high for every control, and even high < low is possible for reversed controls. There's toggle and momentary, and continuous is scaled to be between the two things. Every control really needs both high and low. It should totally be added. But let's say you don't, and have to go work on some other thing and the product is no longer actively maintained. Well then there is at least some hope we can add that feature.

It's possible that some management might object despite previous promises of open access. Here's why that argument is misguided should it be brought up. The firmware is probably extractable by monitoring the sysex transmissions and then disassembling for the particular processor, so it's not like there's an issue of code getting out, it's already out since we can update the firmware which means we can see it. That's not a problem or anything to fear though since you guys have got the supply chain figured out and it being manufactured in a reliable factory, the cost for users to make their own would be a lot more than the manufactured cost. Having access to the code though means that we can improve it. There's this whole scene out there where people write their own firmware for routers, with the more hackable models selling a lot better. In music the DX7 was a famous music example where some guys reverse engineered the firmware and started selling "Grey Matter E!" expansion boards that added all sorts of amazing new features, greatly extending the market life and value of the synth.

There's two big economic upsides to this. One is that you get features added, and engineering work done for free. The other is that the value of the device massively increases because it is hackable, resulting in a longer market life and sales. It's truly win win for everyone.
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

Re: Firmware upgrade with Linux?

Postby jrussell » Wed Dec 26, 2012 1:04 am

Thanks to jscott for joining in the effort of documentation! I have also opened up the issue tracker in qnTools for anyone who wishes to enter suggestions, bug reports, etc.

https://bitbucket.org/jrussellsmyth/qnt ... tatus=open
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Firmware upgrade with Linux?

Postby demcanulty » Wed Jan 09, 2013 11:54 pm

Sorry for the delay on posting, I've been busy trying to cram in prep for NAMM and also working on on my off hours on a somewhat insane light and led installation that's getting installed at a gallery in Oakland this week, verrrry long days. Once that's done I'll have some time to go ahead and clean up the 1.2 javascript sysex generator and post it. I'm beginning to feel pretty good about 1.2 being a stable release, it seems to be doing the job for people, so you hopefully won't have to deal with more changes in the preset structure too soon. I know this is holding you guys up, so I want to get on it as soon as I can, I haven't forgotten you all!
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

Re: Firmware upgrade with Linux?

Postby jrussell » Thu Jan 10, 2013 7:56 pm

I know this is holding you guys up, so I want to get on it as soon as I can, I haven't forgotten you all!

Thats great! the timing actually (for me) will probably be pretty good - I have been spending time figuring out what GUI toolkit to use for mine - since I am not a desktop developer by day, it is something I had to try a few different kits to see what would do what I want it to do.

Since it sounds like you will get us an updated "spec" in the form of new JS app, I will keep the ui/editor part targeted at 1.2 (based on the json) and update the updater part once you give us a new drop.
jrussell
Posts: 70
Joined: Tue Nov 27, 2012 9:16 pm

Dump Presets FROM QuNeo

Postby jrussell » Sun Jan 13, 2013 4:36 pm

This question is for demcanulty:

Is there a way to get the QuNeo to dump its current presets or preset? essentially the opposite of sending new preset data to the QuNeo - so that you can obtain the current settings from a QuNeo that may have been edited elswhere.

If not, I would like to add this as a feature request for next version.

Also - is there room in the QuNeo memory for 1 more preset? I am thinking to make a really nice editor feature having a hidden /non hardware selectable "edit preset" would make it possilbe to have a synchronized QuNeo/Editor function to allow ie: selecting pad to be edited by hitting the pad on the quneo. Basically the hidden preset could be loaded with a standard or the preset being edited, and made active by editor software, then the software can know exactly what is what and be interactive with the QuNeo. once editing is done, it can be stored to the real preset locations.

Thanks

Return to “QuNeo General Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest

cron