Artiphon

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

...I don't think the eventData has a header...? Here's one version of the seven-note "DPC" sequence (song attached) and the data is seven blocks of eight values, each starting with 16; ie just the seven note blocks. The previous "Duration test" (MP3 and CSV) was the same, just the six note blocks in the eventData.

...there's the rest of LoopData though, eg for the attached song:

writeIndex="56" recordStartTime="0" recordStopTime="11882" lastEventTime="4809" nBars="7" eventDataCrc="1ff6d4c4"

Unfortunately I can contribute nothing but admiration. I read along in awe, without understanding much of it. :-)

Okay now I'm thinking that Looper Configuration Values are not in the Event Data BUT I think I now know the message format for CC and PB but I need to prove this out.

Theory: Note is 16, CC is either 20 or 23. In the example I looked at 20 is bound to CC:225 and 23 is bound to CC:74 (possibly via ccB from Looper Config)

CC messages require 4 bytes: 20|23, startTickLSB, startTickMSB, Value

PB messages appear to be 6 bytes: 21, startTickLSB, startTickMSB, unused, valueLSB, valueMSB

I notice that song files have quatizationMode and volume

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

 Have you changed those while the hardware Quantization is on?

I believe I am now communicating on my Mac using the Arduino IDE that I use for my Arduino. I sent the letter 'Q' and it responded with the following!

@BJG145. I've been able to communicate with the Orba and tried a few commands you've found.

I sent a "?" to the Orba and it powered down.. It appears bricked :( I've tried holding VolUp+Power and VolDown+Power. I cannot get a response at all. I'm really hoping you've got advice for me. :)

Good news I re-read your DFU instructions and the Orba App found it in DFU mode.. I then re-flashed firmware, opened a serial connection and set quantize on. I played back many of the songs I'd previously recorded (some of them quite sloppy) and the all sound pretty decent! definitely tighter. Now you've got me hooked on exploring a bit more. I'd like to see if we can read/update some values in there. I can't seem to get it to do the ascii animation thing. I suspect you need a good terminal for that. I need to go back and re-read your posts on this now :)

Now I'm really excited. Chrome also has a Serial API. I predict we will be able to change values from the Editor in the future.. :)

@BJG145 I notice when you press in 'e' in the serial log that you received:

 Detected HW Version: 0

However I receive

 Detected HW Version: 1

I wonder if I have newer hardware since I only got my Orba 1 a few months ago? 

Also I found you get the detailed event log data when you are playing back a song.

Great - glad you got the console working. It would be cool to add a Quantize on/off button to the Chord Fiddler if you can find a way to send these commands with a script or a web page. (I was wondering about creating some kind of terminal script file.) 

The "?" command does the same thing with my Orba. When I mentioned "ASCII animation", it's just a garbage string of characters that probably includes backspaces and things.

Since the Orba remembers quantise mode when you turn it off and on, maybe those elusive looper quantise snap settings stay in flash memory too. If we can find a way to upload/download blocks of Orba's memory, we could try changing things like quantise mode (also key/tempo etc) and comparing memory blocks to find these values; maybe even write to them.

A couple of the console commands seem to be read/write, or there might be a way to do that outside the "Orba terminal" program it's running, and talk to the Orba via the kind of commands seen in the flash-from-file log.  

Interesting about the hardware mode. If you flash it from file at some point, perhaps you could upload the full log for that, though I'm not going to encourage you to start flashing flashing from file etc unless you have to just in case something goes wrong. It's always bounced back for me so far though.

**********************************************

Re: XML, it was after noticing the "mode" tags in the songs files that I tried adding similar tags to the Looper info ones into the song and preset XML, but I haven't managed to detect any change from doing that yet. It might be like the intervals list, where nothing seemed to happen until I changed it in the code.

I'm still interested in the fact that the app code begins with a string that resembles one of these values, though I can't find it anywhere else. I wondered if the start of the app code might hold some of these values, or if it's just be a random fragment of unintelligible compiled code. Changing the app code isn't very useful anyway; definitely a last resort, and you have to match string length with any edits. 

I was wondering about the possibility of encoding values in the looper info header list and searching for that string. The other thing is that the only tag we know about, "quantizationMode", appears in the loop info list as "quantMode", so the other entries might also have different forms for the display entry and the XML field entry, if there even is one. The corresponding list with the "%u" values that I found in that .bin file look like formatting codes in C, from Googling.

...on P10 of this thread, I posted some stuff about downloading/uploading certain blocks of memory in DFU mode, which can be done via commands or via this website...

https://devanlai.github.io/webdfu/dfu-util/

...using 0483 as the vendor ID.

I've no idea what all the various memory blocks in the Orba are, though I'm quite interested in getting a better understanding of how to read/write these areas on MCUs. It might be worth trying to map them out. I don't know if any of the ones accessible from that website might contain Orba memory values that change during use (memory data, key, quantization mode etc). I think those DFU ones might be associated with the STM32 rather than the ESP32, and are probably just static firmware data, but my knowledge of this stuff is very sketchy. It might possibly be worth trying a download/compare/settings-change/download cycle with these.

>"I notice that song files have quatizationMode and volume...Have you changed those while the hardware Quantization is on?"

I've tried the console commands for volume +/-, which work OK, but I haven't tried changing it with XML.

(I don't know if you've tried editing song files, but you'd probably need to create a copy of it rather than editing the original to get any result.)

I've put together some notes on the flash-from-file log and distilled it to a list of file transfers.

 I think what happens is:

1) The App establishes opens communication with the STM32 and sends it:

a)  option_bytes.bin (a few bytes of low-level processor settings)

b)  0x20010000.bin (120KB, no text, name is memory target)

c)  0x8000000.bin (exactly 64KB, includes looper info text from console, name is memory target)

2) The App opens communication with the ESP32 and sends it:

a) 21_X0_CY8C_Touch_A0_2988ebe.cyacd, 19KB for the Cypress touch sensor, data block. Hex?

b) bootloader.bin, 25KB, bootloader messages text

c) partitions_singleapp.bin, 3KB, no text

d) delorean.bin, 680KB, Bluetooth error messages

I'd previously thought that the STM32 didn't do all that much and the ESP32 did most of the heavy lifting, but I'm now starting to wonder if actually the STM32 does most of it.

When I posted the teardown on the Facebook page, someone wrote:

**************************************************************************

The website above reveals four blocks of memory:

Your device has multiple DFU interfaces. Select one from the list below:

DFU: cfg=1, intf=0, alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*64Kg,03*128Kg"

DFU: cfg=1, intf=0, alt=1, name="@Option Bytes /0x1FFF0000/01*048 e"

DFU: cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FF07800/01*528e"

DFU: cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e"

1) 0x08000000 is the corresponding .bin file

2) The "Option bytes"

3) "OTP" is "one-time programmable"; I think we can ignore this, it's an inaccessible preset

4) Not sure, possibly 0x20010000.bin...?

I've been uploading these from the Orba, changing quant setting and uploading again, comparing the results, but nothing much yet. One of them seemed to reduce in size drastically at one point, need to revisit that, but I don't think these are what we want.

When I posted the teardown on this forum, @Tony made some notes about memory:

ESP32 module's internal memory comprises, according to the ESP32-SOLO-1 datasheet: 

448 KB of ROM for booting and core functions.

520 KB of on-chip SRAM for data and instructions.

8 KB of SRAM in RTC, which is called RTC FAST Memory and can be used for data storage; 8 KB of SRAM in RTC, which is called RTC SLOW Memory

1 Kbit of eFuse: 256 bits are used for the system (MAC address and chip configuration)

Winbond 25x40CL (not far from the AKM DAC) is a 4Mb (ie 512KB) serial flash memory.

https://www.digikey.co.uk/en/datasheets/winbond-electronics/winbond-electronics-w25x40cl_f-20140325

The "Winbond" chip might be where the action is, haven't found how to access that yet. There are console options like "W" which says: "Forcing RAM Write to flash" but then closes the connection. (?)

(...Orba needs a firmware reset after that "W" trick...)