Start a new topic

Orba hacking knowledge base

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


27 people like this idea

@ GJ van Mulbregt


Thanks for answering, wonder if theoretically, is not it with the right config, i can get any sound i want? ( tried for a while achieve nothing but ruining the presets :P)

@BJG145 Looking for your thoughts on this:

https://www.youtube.com/watch?v=2GwzbBn7uRw

>"There's "nBars" in the app code and the XML"


I've realised this one's simple; I expect it's been posted about before. You can record a song with one beat, save it, change nBars to eg 32, load it again, then continue. Here's a random quantised 32 bar loop. I kept this one fairly sparse because it crashed when I tried to record a busy one; probably exceeded the note limit.


    

mp3

@ Casey: Nice combination!

Unfortunately I only use the Orba of all ingredients ... ;-)

>"Looking for your thoughts on this"


...so, yes, basically the same kinds of commands I was using. I was referring to this page:


https://docs.espressif.com/projects/esptool/en/latest/esp32s3/esptool/basic-commands.html


...which included this example "to read a full 2MB of attached Flash"...

esptool.py -p PORT -b 460800 read_flash 0 0x200000 flash_contents.bin

I found it was simpler to leave out the port parameter and let the computer find it. I figured, 4MB, double it, and used 0x400000 instead.


I've attached the log. This is how I grabbed the 4MB I posted previously. I noticed that the YT video talks about getting a more accurate figure but I didn't follow the details.


I also tried: 


esptool.py erase_flash


...to wipe the lot, downloaded 4MB again, and checked that it was nothing but FFs, and the Orba didn't even seem to notice. So at that point I decided it couldn't be all that important, though I might have missed something.


From the change log and console commands, I get the impression there's some activity that takes place reading/writing beteen RAM abd Flash storage.


Eg:


* Fixed issue where saving to flash was broken, causing preset loading, song saving, etc. to be broken

* Fixed issue where stuck notes were possible if pads were played during flash writes


I think it may read from Flash to RAM on startup and vice-versa at shutdown. So maybe that contradicts what  was saying, though I don't really know what/where these memory/storage areas are. Perhaps the RAM memory is the Windbond chip @Tony pointed out and the FLash memory is the 4MB on the ESP32.

txt

>"This UI suggests that quantize was once global but they are converting it to per-part"


I was puzzled about that changelog entry:


# 0.15.1

- Disables quantization by default to allow releasing of volume per part


It almost sounds like they sacrificed one for the other; difficult to see how they're connected.

I know I said I'd given up trying to communicate with the ESP32, but I discovered a new piece of info, and now the Orba's not just talking...it's gabbling.


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


The info here is basically correct, but it leaves out a vital piece of information...what you actually do to start communication once you've configured the serial settings.


When connected normally, I see the Orba as a USB serial device on COM13; though as I've said, I'm not sure if that's automatic or because of some other driver I've added. It will be interesting to know if this works 'out of the box', 


image

 


 Open Putty and configure the serial settings accordingly...


image



...but instead of clicking "Open", select "Session" and then select "Serial" to use the options you just configured.


image


I usually start by making sure the Orba is ready by turning it off and on, and I tend to select "Never" in that "Close window" box. Then click: "Open".


At first I just got a black box and nothing happened. Then I hit a few random keys and...messages....!


I would recommend to start by pressing <Enter> (just what I always do) and then try the following one-letter commands, which produce various results


d – Skipping check for debugger

e - Detected HW Version: 0

h - Remix ver 57

q - Toggling looper quantize mode, new mode = 0, 0, 0, 0

q - Toggling looper quantize mode, new mode = 1, 1, 1, 1

s - U3 errs=0x0000 Tx=0, Rx=0, af=0, rx isr=20, tx isr=0

v - (fuin one, toggles the motor on and off )

w - Forcing RAM Write to flash... ("Putty fatal error - Error reading from serial device")

z - ("Putty fatal error - Error reading from serial device")

B - BLE stuff, had to run firmware update to revive it

O - Loads of stuff, ending in animated weirdness


Some of these produce reams of stuff I haven't read yet. This is "B":


image



..."O"...


image



(...had to flash it from a file to revive it afer that one...)


It shows event logs for gestures and what it's playing:


image



Pressing numbers 1-4 shows Looper info...


image



Obvs I was excited to see that "q" toggles quantise on and off, but I haven't got it working yet, even after editing one of the Song files to change the quantisation parameter from 0 to 1.

So I guess maybe delorean.bin is loaded into memory from Flash on startup...? Maybe note data and other settings are stored there, then written on shutdown. The Orba didn't care when I wiped the Flash because it had everything in memory anyway. and just copied it back. The quantise setting must be held in Flash somewhere because the Orba remembers the state of it when it's switched off. It's a needle ina haystack though, and I still don't know where the STM32 and its own  memory comes in. Happy to run another Flash grab if you wanted to suggest some parameters anyway.

So, is there anything to do with v1? I was pissed with v2 annoucement and nothing else than a 10% discount for v1 owners interested in v2. I mean I bought an Orba after waiting quite a while  (months) because Quantization was discussed many times and they said it was high on the priority list. Was confident they would deliver. Instead, with too many feedback requesting that feature, they decided to secretly work on a v2 to offer that feature.


Let's face it, at this point in time they will prolly never add that feature to v1, they want to sell v2 instead. So how is this hack working, is it performing well enough to bother? My Orba is collecting dust for 10 months now and was wondering if I should maybe give it to someone else.

(...corrected Putty images...)


image


image



@BJG145 said:

  • "It almost sounds like they sacrificed one for the other; difficult to see how they're connected."


I too have had this thought and I remember this node:

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

 I suspect this information is being written to the same area and somehow bytes are very limited.. Or maybe they had a build ready for release that passed all volume-per-part tests and they didn't want to risk adding in quantization.

Shift-8 (Asterisk) and Shift-= (+) on my UK keyboard increase/decrease volume, and also give some kind of report about it.


The messages that crop up are to be found in a file called "0x8000000.bin" (attached) which I think is one of the ones that the App creates and deletes during flash-from-file. It also includes text like: "handle_terminal_commands", which is evidently what it's doing. It might contain clues for other one-finger commands we haven't found yet, or what they do.

zip
(40.6 KB)

This is really exciting stuff! I've dabbled with a number of micro controllers and am able to follow most of this. I'm glad you tried setting quantization on in both hardware and software. Its too bad it didn't work. Have you checked if this is "recording" quantization of "playback" quantization? I'm wondering if there's anything for changing Key/ScaleMode/Tempo/Metronome ?

In my experience, quantization with Orba 1 does not work that well. It is working quite well for Orba 2. Quantization is still not that great compared to what we expect from modern software. It actually quantizes during recording, not playback so its not something you can turn on/off to hear the difference.

Matching the coinsole command letters in the previous list with the entries in the .bin file below we get...


s)  U3 errs=0x%04X    Tx=%d, Rx=%d, af=%d, rx isr=%d, tx isr=%d

d)  Skipping Check for debugger...

e)  Detected HW Version: %u Jumping to bootload mode!

w)  Forcing RAM Write to flash...

q)  Toggling looper quantize mode, new modes = %u, %u, %u, %u

B)  Commencing BLE serial pass-through with ESP32 in programming mode...

O)  Commencing BLE serial pass-through with ESP32 in normal mode

*/+) Volume set to %u / %lu counts

9) Info for loop ID

h) Remix ver 57


...and there's also that "v" that toggles the motor on and off. (Could that be the "Palm Event" in the main code? Wonder if there's seekerData for it.) 


Similar entries in the .bin file I haven't accounted for yet, which might possibly be associated with other one-letter commands, includes: 


MemIdx = %lu - MIDI Note at tick %lu, channel %u, note %u, duration %u, von %u, voff %u

MIDI CC at tick: %lu, channel: %u, CC Num: %u, CC Val: %u

MIDI Pitch Bend at tick: %lu, channel: %u, PBend Val: %i


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


>"I think I’d read somewhere something about how if you want to talk the ESP32 it has to be in a different mode."


Given:


B)  Commencing BLE serial pass-through with ESP32 in programming mode...

O)  Commencing BLE serial pass-through with ESP32 in normal mode


...at least I wasn't imagining things...;-)


I think normal mode is a normal connection, and with that, "O" ends up doing...something. (Animated ASCII event-monitor stuff.) "B" ends up with a question mark and a firmware reset. (I'm still wondering if programming mode might possibly be indicated by the white spinning circle you get if you pull the plug during an update. I might test that but I've done enough firmware resets for one day.) 

Login or Signup to post a comment