QuNeo technical/scripting questions

TheSupport@KMI
Posts: 726
Joined: Wed Jul 13, 2011 12:30 pm

Re: QuNeo technical/scripting questions

Postby TheSupport@KMI » Fri Sep 14, 2012 3:50 pm

TomSwirly:
The .pyc files on Mac get installed into the Live application package itself. Right-click on Live and select "Show Package Contents", then Contents ---> App-Resources ---> MIDI Remote Scripts ---> QuNeo. They're all in there.

To e'erybady:
I would love to post the code for absolutely everything, but unfortunately I can't...
2, 3, 5, 13, 89, 233, 1597, 28657, 514229, 433494437, 2971215073
isobarxx
Posts: 1
Joined: Fri Sep 14, 2012 5:02 pm

Re: QuNeo technical/scripting questions

Postby isobarxx » Fri Sep 14, 2012 5:05 pm

Okay. ...But, you know we can just decompile them, right? Can we post modified scripts that are derived from yours? I would assume not, but I figure I should ask.
TheSupport@KMI
Posts: 726
Joined: Wed Jul 13, 2011 12:30 pm

Re: QuNeo technical/scripting questions

Postby TheSupport@KMI » Fri Sep 14, 2012 5:14 pm

I don't really think there will be a problem with users posting things like that. Personally, I would encourage that.

The most amazing things always come from users hacking the defaults.

└é┬ ┼He haXδΓíÑg ßΣgìñ!!!11!!1!
2, 3, 5, 13, 89, 233, 1597, 28657, 514229, 433494437, 2971215073
TomSwirly
Posts: 79
Joined: Sun Aug 07, 2011 9:04 am

Re: QuNeo technical/scripting questions

Postby TomSwirly » Fri Sep 14, 2012 8:38 pm

Aha!

This explains why:

1. I couldn't find the scripts.
2. I installed the scripts, then I installed a new version of Live, and then I had to reinstall!

I'll report back tomorrow with results, let us hope...
thisissami
Posts: 1
Joined: Fri Sep 14, 2012 9:08 pm

Re: QuNeo technical/scripting questions

Postby thisissami » Fri Sep 14, 2012 9:11 pm

just curious - why is it that the script can't be released?
mooter
Posts: 101
Joined: Sun Sep 02, 2012 9:34 am

Re: QuNeo technical/scripting questions

Postby mooter » Sat Sep 15, 2012 11:07 am

In that case, here's the decompiles I ran: https://www.box.com/s/zaws4hvxfku0xmg7jhpv

The reason there is a folder with some of the same is a different program decompiling. The ones that decompiled online had a limit so the quickest easiest way to do the rest was with Linux. Since there wasn't any support for the samy python version the decompiles aren't 100% accurate if that's even possible; I dunno, I'm a newb, but that's what I got.

What we have (and I look forward to the next version coming up soon) is a nice intro but if you look at some of the nativekontrol stuff you can see how much power scripting has (ie having "modes" in 1 preset; wouldn't it be nice to have presets within 1 preset?) I have a padkontrol so you can switch between control surface track control to drum rack mode to 16 step sequencer to learning midi notes and playing back. Granted, there is some involvement with Bome's and maybe autohotkey but still...

Personally I'd love to learn python and try and do something like that from scratch but I don't have the time right now. But it doesn't mean there can't be some copy/pasting from other surface scripts like Launchpad or livid stuff and just modify what needs to be modified...some scripts leave decompiles, some don't....I think...

Other than that, thanks for what you guys have done and I hope things aren't too stressful on your end, otherwise...I'm looking for work:p
TomSwirly
Posts: 79
Joined: Sun Aug 07, 2011 9:04 am

Re: QuNeo technical/scripting questions

Postby TomSwirly » Sat Sep 15, 2012 1:55 pm

I'm reading through these now - very interesting.

Several things pop out.

1. There's a missing module, clearly from Ableton, called "Live" that all the files import. It's actually only used in three places:

Code: Select all

QuNeo.py:83:      app = Live.Application.get_application()
QuNeo.py:293:         return EncoderElement(MIDI_CC_TYPE, channel, value, Live.MidiMap.MapMode.relative_two_compliment)
SpecialTransportComponent.py:115:      if not(control == None or isinstance(control, EncoderElement) and control.message_map_mode() is Live.MidiMap.MapMode.relative_two_compliment):


This doesn't seem like much of an issue, it's pretty clear what's going on here.

2. There's a decompilation error in four of the files: "STRANGE ABSOLUTE JUMP!"

This is the most worrisome part for me. It seems pretty clear that this means that the code that we see is not in fact, completely correct. But what's changed? And where?

Searching for "STRANGE ABSOLUTE JUMP" only found other decompiled files with the same message - there was no real indication as to whether this worked or not.

There's no reason you shouldn't be able to correctly decompile Python code, but that doesn't mean that the tool does it 100%.

3. A code review!

The code is pretty decent, from what I can see.

There are some "unpythonic" patterns here, very minor - for example,

Code: Select all

if not value in range(128):
  raise AssertionError
is exactly equivalent to

Code: Select all

assert value in range(128)
.

However, this might well be due to the decompiler.

What's more disconcerting is that some of the code doesn't make sense...

Code: Select all

      if self.is_enabled():
         self.is_enabled()
         if value != 0:
            new_tempo = 1.0
            real_tempo = new_tempo + self.song().tempo
            if real_tempo < 20.0:
               real_tempo = 20.0
            self.update_tempo(real_tempo)
         else:
            None
      else:
         self.is_enabled()


self.is_enabled() almost certainly does not have any side-effects, so why is it being called like a function?

Now, this won't cause anything to break itself BUT it's a little disconcerting.

Where to go from here.

I'm unfortunately out of time right now, and I might not have time to continue this for a week or so... but here's where I would go next.

1. Try to recompile the software and see if it runs the same as the original.

My issue with doing that is that I haven't really used the QuNeo at all with the original software - I just got back from Europe a few days ago and found the unit waiting for me. So my next step would have to be to spend a few hours playing with the unit and using it.

Once it's understood how the software works when it works correctly, the next step is to recompile the code and put it back over the original software and see if it works identically.

The one issue in compilation there is that one missing external reference, Live. I'll bet that won't be too difficult to find now we know where everything is.

2. If it doesn't recompile, try to get that to happen.

If the recompilation fails, we're in a less-than-good state.

There aren't really very many decompilers out there - however, printing out Python bytecode is perfectly doable and it's pretty high-level and readable, so it would be quite possible to compare the byte code to the decompiled code and figure out what was wrong, though it would be a lot of work if you had no idea where the problem was (one advantage is that it's almost certainly in the four files that had decompilation errors).

3. Once it's recompiling, we can study the decompiled code to create our own versions.

but see the...

APPENDIX: Why aren't we seeing the original? and other legal issues.

Looking at the history of the Live/Python interface model, it's pretty clear that it comes with some sort of NDA that prevents client companies from revealing information about it (boo!)

Luckily for us, decompilation of software for study purposes has been shown to be legal in several court cases - and also it's probably not really useful for Ableton to go after hobbyists.

If we release derivative versions of this code, we are potentially infringing on KMI's copyright on the code. KMI is clearly not going to give us explicit permission to do this, it'd be a terrible legal idea for them, but unlike trademarks, you're not required to defend your copyright, so there's no downside for them if they do nothing.

I believe it's extremely likely that if we created derivative versions of the drivers for non-commercial reasons that KMI would simply not comment directly one way or the other.

If that's not the case, coming up with our own original driver by studying the decompiled code has been shown in court to not infringe copyrights, as long as we can prove that we didn't just create a derivative version.

Thanks for reading.
TomSwirly
Posts: 79
Joined: Sun Aug 07, 2011 9:04 am

Re: QuNeo technical/scripting questions

Postby TomSwirly » Sat Sep 15, 2012 2:52 pm

Just a note - after musing on this, I now believe the strange unPythonic constructions are almost certainly an artifact of the decompiler and the original code was in fact the correct "assert" statement.
lokey
Posts: 11
Joined: Wed Aug 29, 2012 8:33 am

Re: QuNeo technical/scripting questions

Postby lokey » Tue Sep 18, 2012 8:10 pm

and this is why the absence of open source is absurd here. All this is just muddying the waters. Come on folks, you talked about an open source hardware platform, what possible reason is there to chose not to release something as live api python scripts? Many other vendors do this as a matter of course. Hardly an unreasonable expectation, and one well with your grasp, which would be entirely seen as a goodwill gesture.
face
Posts: 20
Joined: Fri Sep 14, 2012 2:38 pm

Re: QuNeo technical/scripting questions

Postby face » Wed Sep 19, 2012 1:19 pm

I too would love for the script to be released.
Last edited by face on Thu Oct 04, 2012 8:28 pm, edited 1 time in total.

Return to “QuNeo General Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest

cron