Artiphon

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

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.

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:

Found these nuggets :) These could be very useful..

https://storage.googleapis.com/orba_firmware_updates/appcast_fw.xml

https://storage.googleapis.com/orba_software_updates/appcast_beta.xml

Well spotted. I'd been looking for those.

I setup a song with these nodes edited like this:

<Mode name="Drums" quantizationMode="0" volume="200">
...
<Mode name="Bass" quantizationMode="1" volume="200">
...
<Mode name="Chords" quantizationMode="2" volume="200">
...
<Mode name="Lead" quantizationMode="3" volume="200">

 The icons from above appeared in the Orba App:

@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)

Sharing a Daft Punk loop that sounds pretty good with quantize on.

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+/-

I wonder if the quantize mode icons will eventually be clickable buttons that take you into the settings. (They're not at the moment.)

Can you also see the code for the "Clear" graphic...? I was wondering how the clickable areas are implemented. Is the event handling tied to the graphic code in some way...?

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

Bullseye

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.

">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.