>"I'm wondering if there's anything for changing Key/ScaleMode/Tempo/Metronome?"
Good question, I was thinking there might be a tempo setting somewhere, and it would be interesting to find out whether the way the App changes key involves the same kind of communication as the console...
Looking at lines 9-12 as a set:
Movement Metric Tilt, Spin, Move, ShakeCC 2001
Touch Metric Radiate, Press, Vibrato 3111
Note Event Tap lead/chord, Bump, Shake 0000
At line 13, that leaves me wondering why Vibrato has 0 like the Events instead of 1 like the other Metrics.
>" It rebooted itself and when it returned a song that I was working earlier was now in memory"
The same thing happened to me once. The Orba was playing a song, then it crashed, and started playing an earlier song, which I'd always found puzzling. I hadn't made the connection. I even thought I might have imagined it, but the thing was gaslighting me.
To recap, it's possible to talk to the Orba in several different modes.
1) DFU Mode. In this mode we can talk to the STM32 via the App’s firmware update, via dfu-util.exe, or the DFU website. It presents four different storage areas shown by dfu-util.exe -l.
serial="STM32FxSTM32"
[0483:df11] alt=3, name="@Device Feature/0xFFFF0000/01*004 e",
[0483:df11] alt=2, name="@OTP Memory /0x1FF07800/01*528e", serial="STM32FxSTM32"
[0483:df11] alt=1, name="@Option Bytes /0x1FFF0000/01*048 e", serial="STM32FxSTM32"
[0483:df11] alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*64Kg,03*128Kg",
The flash-from-file log has entries such as:
dfu-util.exe -d 0483:df11 -a 0 -s 0x20010000
Here 0483:df1 identifies the device, -a identifies one of the above four storage areas by their “alt” number, and -s identifies the address for the file transfer.
The tiny low-level “Option Bytes” area is refreshed in some way, and “Internal Flash” receives 0x2 (no text, changes) together with 0x8 (console text, no changes). These files are apparently created by the App, which drops them in a temp folder and clears them away afterwards. As for the other two storage areas, “OTP” is non-writeable and “Device Feature” doesn’t seem included.
2) Normal mode. In this mode we can talk to the ESP32 via the App or the console. I’ve found that if you come out of the App, you can’t connect to the console until you’ve powered the Orba off and on again, as if the Orba hasn’t disconnected ready for the next call.
3) Programming mode. The second half of the firmware-from-flash process turns this on and then off again automatically. The only way I’ve found to get it into this state and keep it there is via console “B”. Unfortunately this doesn’t always seem to work reliably (it should end with “waiting for download”), so I’ve sometimes had to go through flash-from-file, then turn the Orba off and on again to be able to connect via the console, then use “B” to get it into programming mode. Once there you can carry out Flash read/write via esptool.py.
During flash-from-file, the ESP32’s Flash receives a system file called bootloader, then delorean.bin, then another system file called partitions_singleapp. These three are included in the downloadable firmware zip. One thing that puzzles me is that the flash-write entries for the first two both start with:
Writing at 0x00010000
Why carry out two consecutive writes to the same place…? Maybe it’s ESP32 standard operating procedure. (The small final file goes to 0x00008000.)
The Orba looks unresponsive in both DFU and Programming modes. There’s also another couple of states it can get stuck in. If you pull out the USB cable about halfway through flash-from-file you can get into an unresponsive spinning-white-circle pattern which might relate to flashing the sensor. Sometimes I’ve found it can also get into a state with a flashing Oct light; and I’m not sure what that means, but although it still plays, I’ve sometime had to use flash-from-file to be able to connect to it again when it gets like that.
I hadn’t appreciated that these MCUs seem to work basically like a miniature computer; loading programs and data from storage into RAM, working with them, and saving them again. (?)
My current theory is that flash-from-file preps the STM32 with 0x8 which runs the console and possibly the main performance activity, and 0x2 which is still a mystery. It then preps the ESP32’s 4MB Flash with delorean whch handles Bluetooth, maybe performance data, maybe system settings, possibly sample data if the function was available.
On startup, this stuff is loaded from the 4MB Flash storage into the 4MB Winbond aka Tony’s chip.
On shutdown, and possibly also other times, it gets written back. I say “possibly other times” because of the changelog comment: “Fixed issue where stuck notes were possible if pads were played during flash writes”.
I had a quick look to see if there might be a way to examine RAM contents. It seems external RAM can be configured for the ESP32 in various ways described here:
I'd guess that it uses the default, “Provide External RAM via malloc”, given that “malloc” crops up quite often in the .bins. I can’t see a simple user-friendly utility like dfu-util or esptools.py to interrogate it though, and since it gets written to Flash at shutdown anyway I’m happy to stick with those. It’s just worth bearing in mind that if you make changes between Flash grabs without powering off, you might not capture the change. I seem to remember that console “W” forces RAM write to Flash (before kicking you out of Putty) so I’ll experiment with that.
In light of RAM/Flash writes I’ll have another go at trying to capture changes in the ESP’s 4MB Flash after changing performance data and settings…
...as well as the quantizationMode parameter in the "Mode" tags...
<Mode name="Lead" quantizationMode="0" volume="200">
...the Song presets have entries like this which are probably tied up with loops and quantisation.
<LoopData writeIndex="0" recordStartTime="0" recordStopTime="0" lastEventTime="0"
nBars="0" eventData="" eventDataCrc="ffffffff"/>
The "MemIdx" (memory index?) entries might be useful...
MemIdx = 148 - MIDI Note at tick 2759, channel 1, note 52, duration 114, von 107, voff 51
MemIdx = 156 - MIDI Note at tick 2759, channel 1, note 59, duration 114, von 107, voff 51
MemIdx = 164 - MIDI Note at tick 2759, channel 1, note 64, duration 114, von 107, voff 51
MemIdx = 172 - MIDI Note at tick 2759, channel 1, note 68, duration 114, von 107, voff 51
MemIdx = 180 - MIDI CC at tick: 2822, channel: 0, CC Num: 1, CC Val: 0
MemIdx = 184 - MIDI CC at tick: 2858, channel: 1, CC Num: 255, CC Val: 44
MemIdx = 188 - MIDI CC at tick: 3462, channel: 0, CC Num: 1, CC Val: 7
MemIdx = 192 - MIDI CC at tick: 3839, channel: 1, CC Num: 255, CC Val: 83
MemIdx = 196 - MIDI CC at tick: 3839, channel: 1, CC Num: 74, CC Val: 93
It could potentially show the structure of a block of note data if we could find a way to copy it off.
In the meantime, I guess it should be possible to reconstruct it from the log.
Here's a simple tune with Bass. I've been messing around with quantise and I think it might possibly have done something to it, because I don't think I played it that badly.
I've attached the data from the console. All rows except "MIDI Note" can be discarded. The note data loooks plausible. In order to reconstruct a MIDI sequence using the timing data I'd be thinking Max/MSP, if I knew how to use it; or maybe one of those music programming languages like Sonic Pi.
This log data will be invaluable to breaking down the eventData in a song's LoopData nodes. I suspect its the exact same data from the MemIdx above. Eventually I'll build the Generic Fiddler but we can just paste the eventData from a song like the one below into the experimental fiddler but I think it might be too long.. Quantizing would just be rounding the tick values to the nearest tick..
<LoopData writeIndex="504" recordStartTime="0" recordStopTime="0" lastEventTime="3484"
nBars="4" eventData="INgAKkswRwAggQAqUi5ZABBoAC1ZKpoAIO4AKkMnNwAglgAqTDNPABBsACRKKKcAIBUARQsAWgAQ7wAqSi1CABCMACpLLlQAEFkALWMrpwAQ+wAqSCw/ABCMACpPLVAAEGoAJFAlkQAgHABFBABaABDMACpTLkMAEI4AKkssVgAQYQAtWCeBABD+ACpUMkYAEIwAKlo3UQAQWwAkSyiOACAbAEUFAFoAEOkAKlYxPQAgIgBFBABaABBoACpOMEoAEFwALUUwawAQ8gAqXjVFACAeAEUEAFoAEGYAKlI1SgAQcwAkVSl4ACAbAEUHAFkAEMEAKkkwRAAQogAqTTJEABBLAC1PHnsAEPkAKlk4RgAgJABFBQBZABBvACpJNkIAEFkAJFotnAAgGgBFBQBZABDjACphNzsAICAARQMAWgAQaAAqTjFDABBqAC1TI2wAEPAAKlw2OAAgHwBFBABZABBxACpVNEUAEFQAJF0upgAgGQBFCQBZABDSACpaOjsAIBwARQUAWgAQagAqSzFGABBkAC1eNHwAEAQBKlw0NgAQigAqUjVIACBIACRnPXoAEBsARQIAWQAQ6gAqVy49ACAhAEUFAFkAEGQAKlAySwAQXQAtUiZvABD9ACpoOD8AICAARQcAWgAQUwAqUjk0ABBeACRXLKUA"
eventDataCrc="fe32e7bf"/>
Carrying out these 4MB Flash comparisons is difficult because "B" for "Programming mode" is very flaky. It often stalls and I have to tinker around with the Orba for a while, flashing it, sending new songs to it, restarting it, until I can get it back into programming mode again...and by that time you've lost the changes you were trying to compare.
However, I've managed to get a new grab to check against the one I posted before, and the only difference seems to be in a memory area immediately after delorean.bin containing a lot of this...
LE_LOCAL_KEY_IRK = 10d037d698afadd868f0098d1d9afa42
LE_LOCAL_KEY_IR = 47b6e7029880abba8de07bf71e3fa944
LE_LOCAL_KEY_DHK = a85872664501ebb925cf1ca3af6854e4
LE_LOCAL_KEY_IRK = 10d037d698afadd868f0098d1d9afa42
LE_LOCAL_KEY_IRK = 10d037d698afadd868f0098d1d9afa42
LE_LOCAL_KEY_IR = 47b6e7029880abba8de07bf71e3fa944
LE_LOCAL_KEY_DHK = a85872664501ebb925cf1ca3af6854e4
LE_LOCAL_KEY_ER = 98db770f480e43c82c56bd27c24ab40d
From a quick Google, this looks like Bluetooth data. (?) It tends to confirm what the "parttion list" indicated, that this storage area is used primarily for delorean and Bluetooth. I'm now thinking that the write-from-memory that occurs on shutdown may send data to a couple of different areas; this Bluetooth stuff to the ESP's Flash (though why you'd want to keep it I've no idea), and other things to the STM32 Flash (eg 0x2). I think I'll take another look at that, because it's much easier to access.
Still not sure whether those above strings might contain note data. It would seem a strange and unlikely format for it. On the other hand, I thought the STM Flash size was more limited...will need to check...
Figuring out the calculation of ticks to notes will be important. I found this to help
...yeah, the STM32F730 only seems to have 64KB Flash.
https://www.st.com/en/microcontrollers-microprocessors/stm32f7x0-value-line.html
Mind you, it does run out of notes pretty quick.
Here's a set of files from a simple Bass loop:
1) MP3 recording
2) MIDI recording (from Orba USB to a DAW)
3) Song file
4) Bass LoopData from the song file
5) Full loop info from the console with header
6) MIDI notes only from the loop info
Looking at (6), the last note in the data is the first note in the tune. Maybe that's just the timing of the playing. There's been no attempt to quantise it. It would be interesting to try and change one of the notes.
I found this a bit of a fiddle, but hopefully it's right.
>"This Bluetooth stuff to the ESP's Flash (though why you'd want to keep it I've no idea)"
...pairing info, I suppose...?
When I was looking at it yesterday, I think it was showing a log like this while playing at one point.
I wasn't able to get into that mode just now, but comparing it with the "loop info" file from this other loop might be helpful while trying to figure out the LoopData string.
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
27 people like this idea