Start a new topic

Orba hacking knowledge base

This thread is intended to gather the feedback of Orba tinkerers.


29 people like this idea

I just searched the app code for "groove", and you can find references to "orbagroove".


A while back I was messing around with firmware updates on another MIDI gadget called a Misa Tri-Bass from Windows, and came across "Teraterm macros". The update worked via a batch file with the command:


ttpmacro.exe misa_tri_bass.ttl


I've attached the .ttl file. You'll see that it's a set of commands that connect to the device via USB and update various files on it. I think both this and the Orba use some kind of serial/USB connection. The Teraterm software was included along with the update files. 


The Tri-Bass was based on Linux. The Orba is very different, of course, but it gave me the idea that it should be possible to write a script or macro that runs a set of commands to establish a connection, issues a "q" command, disconnects etc., basically working in the same way as the flash-from-file utility. We might not need to find the "q" command anywhere else; we could just use the one we've got, but wrap it up in a friendler "Quantise on/off" program, possibly as a feature of Chord Fiddler.


It occurred to me that flash-from-file does a complete reset including things like key change, Maj/Min, quantisation; stuff we don't currently know how to access - and it's basically just a list of files that get flashed in various ways. Now that I've got esptool.py from the logs working, I think I can do the whole process manually a step at a time, so it's just a case of going through it and working out where the reset happens. I think it might be in that 4MB flash using esptool.py. 


With espytool it looks fairly straightforward to read and write arbitrary blocks of memory; I've already grabbed the whole 4MB block; so if it does turn out to be that one it may be possible to gradually narrow down where in memory some of this stuff is.

ttl

Cool. I think I could use Chrome's Serial API to send a "q" to the Orba. However, I'm not sure this makes it any easier for anyone as I think they would still need to install driver(s) for this to work. The Orba App must use a different communication method (USB?). I've downloaded a trial version of Hopper and disassembled the Orba App. There are lots of references to "quantizationMode" and "Serial". Slow and Steady.. There are also references to QuantizeIcon.. 

I just remembered I ripped some graphics out of the App a little ways back... I just reviewed and hadn't noticed this:

image

So its in there somewhere.. I'm guessing Artiphon has suppressed these until a later date.. Orba 2

Well spotted. I'd been looking for those.

@BJG145 Remembering from my C days, its possible that changing:

quantStartSnapTicks: %u

  TO

quantStartSnapTicks: %p


Might output the memory address of quantStartSnapTicks.. Worth a try..

I get the sense that Orba 1 hardware quantize modes run the show and that the software quantize values do nothing at this point (other than change the UI)

On this node:

<Mode name="Drums" quantizationMode="0" volume="200">

 volume also has no impact (yet). Setting volume to 0 changes nothing. The only way to change the volume is by editing the channel volume via hardware with A+[Drum|Bass|Chord|Lead Button] + Vol+/-

>"Remembering from my C days, its possible that changing %u to %p might output the memory address"


Bullseye


image


Thanks for trying! Unfortunately that is outputting the Hex value of the same numbers and not the memory addresses. :( I'm currently hunting through 0x20010000.bin with no luck. I could try to replace all instances of those numbers (casting the net very wide) to see if anything happens but there are many instances of those numbers and I don't feel confident we'd find it. 120 = 0x78, 240 = 0xF0 and 480 = 0x01E0. You can hunt for those in a Hex Editor but they appear in many places. 01E0 appeared 6 times in 0x80000000.bin and I only replaced 1 of them. Maybe I should have changed them all to see if the 480 changed.

Here is one with all the 480s changed to 481s.

bin

">Unfortunately that is outputting the Hex value of the same numbers"


...oh well, worth a try. :-)


I mentioned that I'd grabbed 4MB of Flash memory from the ESP32; here's a copy of that.

bin
(4 MB)

...at first glance it starts with the "delorean" .bin and carries on from there. (Delorean is one of the files in the firmware zip.)

zip

...missed out...


0.14.15

This build is based on 0.14.14 and has no key changing support


The feature of changing key via the Oct pad seemed to briefly exist in 0.14.13 only. Reviewing those googleapis XMLs, I'm slightly hazy on whether the change log is referring to the app or the firmware or both. Eg you can access 0.14.13 of the App, but only 0.14.11 or 0.14.15 of the firmware.

>"I believe that thinner and thickener modes might have a bearing on Groove but might also be used to thin the amount of CC data or interpolate additional values if required."


0.13.2

Fixed issue with CC thinner channel assignments that could crash looper

>"What I'm most interested in at the moment is beatLengthTicks and quantStartSnapTicks. In the DPC example, these are 480 and 120. So I'm thinking this 1/16 note quantization."


0.14.18

Quantization is turned on by default (constant length, snap to 1/16 notes)


Login or Signup to post a comment