Start a new topic

Orba hacking knowledge base

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


29 people like this idea

(Re: that 4MB flash RAM I mentioned, you can erase it entirely, confirm that it contains nothing but FFs, and it makes no noticeable difference to anything.)

...been hunting high and lowe for quantStartSnapTicks, but no luck yet.


I found this text in the App in the kind of area I was looking through while trying to understand the Modifiers and the Seekers.


Note

Event

SnapToGrid

AsPlayed

Major Chords

64358c1f-2ef5-4fd0-b3fd-ad8c4f93b839

Pressure

Metric


It made me wonder whether some of the quantisation settings might be hidden somewhere like the ModifierData for the Tap event. 


I just tried running the artiphon_esp32_programmer command that handles the esptool.py transfers, and that didnt toggle quantise either, so I'm coming to the conclusion that it might be something that's done by the Orba App itself outside the events in the log.


I noticed something else a bit strange about quantise and the App. It goes like this:


1) Play a song with quantise enabled, all fine.


2) Run the App and load a song containing eventData with quantisationMode set to 1 (so that the icon appears), but playback is non-quantised.


3) Quit the App, turn the Orba off and on again, and play the song. It's the one you loaded from the App, playing quantised.


...so it seems that quantisation is enabled throughout, but playback in the App when you initially load the new song is without it.


I also wondered if quantisation enabled/disabled is separate from quantisationMode=0/1/2, and console "q" changes both.


1 person likes this

I've attempted to carry out all the file flashing from the log, but none of it toggled quantise. 


Here are some notes on the procedure for reference. (I've attached a copy of the application's flash log, and my manual version.)


* * * * *


The Orba begins in DFU mode. The transfers start by using dfu-util to do something with the small system file option_bytes.bin that seems to involve grabbing it and then sending it back with different parameters. Then dfu-util sends the larger 0x00002000.bin and 0x00008000.bin files. 


Next a custom program called orba_capsense_bootloader resets the touch sensor via 21_X0_CY8C_Touch_A0_2988ebe.cyacd


The Orba restarts so it's no longer in DFU mode, and is set to programming mode. Another 

custom program called artiphon_esp32_programmer transfers the three files from the firmware zip; delorian.bin, bootloader.bin and partitions_singleapp.bin


The commands for dfu-util can be copied and pasted from the application's log. The parameters for esptool.py are a bit more obscure, and you have to have to switch in and out of various modes at different points to carry out the steps and check the state of quantise, using console "B" to put it in programming mode before guessing at the esptool.py parameters. 


You need to turn the Orba on and off at various points to work on it via the different programs; eg if you run the App you need to quit it and switch off and on before using Putty. You need to quit Putty before you can use esptool.py.

 

 

 

 

 

 

 

 

 

txt
txt

1 person likes this

The versions might be a combination of app/firmware maybe.


>"Here is one with all the 480s changed to 481s"


Good idea, no result yet but one way to approach it if I can narrow down the file. 

Its interesting that Quantization can be turned on/off with an App version? Maybe the defaults are in the App and get pushed to the Orba when it connects?

...another one I noted was:


0.13.18

Limit max loop length to 8 bars 


It sounds like it might be possible to change that if it was useful...? Earlier versions are available for testing from googleapis, eg the app/firmware for 0.13.0.

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


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

...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've been taking another look at the change log, and some of the comments are quite interesting.


0.12.3

Fix major issue sysex messages would not be transmitted by ESP32 to STM32 in many cases

Default pitch bend range set to 2 from 48


0.13.1

Fixed issue where Orba could crash if the play surface was extensively palmed


0.13.7

Added root notes and scale to pattern data

Added song root note and scale to Orba metadata


0.13.16

Changed default looper mode to allow up to 1 bar of silence at start of loop, first notes played back as recorded on time grid rather than snapped to start of loop.


0.14.0

Added feature where loops are 'intelligently' ended and notes at the end of the first bar can move to the end of the loop. Loop now ends when last note is played, not when A button is pressed.


0.14.13

Added ability to change Orba's key by sliding on the OCT pad


0.14.17

Removes ability for looper semitone shift

Add FW field to comms to allow app to turn metronome on / off


0.14.18

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


0.15.0

This version has quantize on by default

Added 'groove' quantize option


0.15.1

Disables quantization by default to allow releasing of volume per part

md

1 person likes this

I'll go back to plan A, start by working through the flash log and see which one resets quantise. 


1 person likes this

That Flash.bin file appears to be communication/wifi code. 


1 person likes this

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

">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)
Login or Signup to post a comment