I’m such a java noob but rather good at python that I thought I’ll do it the way I know best. I’m trying to make sure it’ll also run on other platforms like you said. Using Python3 currently.
But yeah GitHub would be I nice platform I think. Should we create an organization so we can group multiple repo’s if needed?
What I don't get is, why isn't the firmware open source when TE themselves are using several open source programmer languages ? Or is this something different ?
Because the licenses are permissive in that they allow whoever is using the libraries to create a closed source product, and this is normal. Also TE integrated these by adding their own closed code.
Actually I think we’ll end up with two groups of people - the ones who want to customise their OP1 while retaining its limited functionality, and the ones who think the OP1 can do much more and see TE as complacent, and who will set about finding ways to replace TE’s bespoke code with their own. There are obstacles to this second group gaining speed but it would be deeply cynical to ignore them. Us.
Actually I think we'll end up with two groups of people - the ones who want to customise their OP1 while retaining its limited functionality, and the ones who think the OP1 can do much more and see TE as complacent, and who will set about finding ways to replace TE's bespoke code with their own. There are obstacles to this second group gaining speed but it would be deeply cynical to ignore them. Us.
The only concern here is that once the floodgates are opened with someone creating a custom firmware, that TE decides “oh hey now we don’t need to support this anymore or fix bugs or create new sequencers/synths” because there will be other people doing it. Considering the lag between updates from TE as is, I wouldn’t be surprised if they seized the opportunity to solely focus on newer products. Just playing devil’s advocate to the unbridled enthusiasm this thread is rightfully receiving.
While I think changing graphics is fairly benign, if custom firmwares ever start being passed around I think it would be a huge headache for TE as customers make support requests with altered firmwares or bricked units. They are too small/nice a company to make trouble for. I hope that never comes to pass, but I guess I’m way past my hacking days and just appreciate the product as-is.
[...] There are obstacles to this second group gaining speed but it would be deeply cynical to ignore them. Us.
The only concern here is that once the floodgates are opened with someone creating a custom firmware, that TE decides “oh hey now we don’t need to support this anymore or fix bugs or create new sequencers/synths” because there will be other people doing it. Considering the lag between updates from TE as is, I wouldn’t be surprised if they seized the opportunity to solely focus on newer products. Just playing devil’s advocate to the unbridled enthusiasm this thread is rightfully receiving.
Agree, @GCF. Then again you should consider the same - the interval between updates and what the updates do - also when you judge how well TE are currently supporting what is their flagship product. I think, in weighing the arguments for buying an OP1 all of us have included the promise of firmware updates. One cost of TE “seizing the opportunity to solely focus on newer products” would be that the community would know not to trust them to release updates themselves, which would make it difficult for TE to ship with imperfections. A custom firmware would be bold, a cheeky move, but the claim that the OP1 is different, self-sufficient, feature complete, is in conflict with its obvious greater potential, existing bugs, and artificial limitations. I think researching the OP1’s inner workings is a great idea, an insurance if you wish, if not a basic need to push our gear beyond its limits, and so I admire the effort, and am trying to contribute.
@eesn Agreed on the value of learning more about it, and I am very excited about even just changing the graphics. I think an end of life on firmware updates is inevitable. I wonder to what extent TE views the bugs and limitations as real bugs and limitations that they want to address, or if they are wanting to keep innovating by providing new features and see bug fixes and such as something they have to implement in fear of the backlash of loyal customers. It seems that the most frequent complaint is about clicks on tape, which they are trying to fix. After that, it will be interesting to see how much of the core OP-1 firmware as it has existed since the start would be modified by customers’ “nice-to-haves” that aren’t technically bugs. I don’t see a day in which all OP-1 users will agree on the OP-1 being feature complete, bug free, and free of imperfections – which is ultimately what will always work against TE when releasing any product.
The comand I use to recompress the FW is: tar cf - content/ OP1_vdk.ldr te-boot.ldr | xz --format=lzma -C crc32 > op1_14203.op1
Then you need the crc: crc32 op1_14203.op1
And you need to pre-prend the CRC in reverse order (Little Endian). I use "hexer" manually for that but in a script you'd probably use dd or something.
So is there actually TWO CRCs? One for the lzma-compression process and another added to the actual lzma-file itself? I’m using your command and for some reason the OP isn’t accepting the file at all. I’m trying to copy paste it in. Smaller files of 15mb or smaller go in with no problem. The file from your command on the latest official FW is about 16mb. My repackager seems to have the same problem. Any ideas?
@TabascoEye I’m now using tar cf - content/ OP1_vdk.ldr te-boot.ldr | xz --format=lzma -8 > …/op1_076-repack2.op1" and adding the CRC with my Python tool.
I’m getting the following output:
Found firmware package…
Calculating CRC-32…
CRC-32 OK, start unpacking…
Alloc failed!
Decode failed, aborting!
No firmware written. Try again.
Seems like maybe there’s something weird going on with my compression…