Start a new topic

Orba hacking knowledge base

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


27 people like this idea

...App code...


QuantSnapToGrid_On.svg

QuantSnapToGrid_Off.svg


Do we know what those look like...?

No I don't. But I imagine they are just like these:


1 person likes this

I think these will become buttons with the next release so I'm not chasing these anymore. I am very  interested in quantStartSnapTicks because I don't think they have plans to make that configurable 

Good luck. ;-)


It seems to be referred to as SnapToGrid so I'm going to hunt for that. I wonder if there is any metadata in the songs that might have this? Maybe they will add it so that we can hack Groove parameters or snapToGrid parameters in the future.. :)

In the meantime I've had an idea.


1) Create a script to send "q" to console and bundle it with Chordfiddler 

2) Put out an ad


"New Orba-Q unlocks the power of your Orba-1 with the power to add quantisation to your loops as well as customising chords and scales! Introductory offer for only £20. Please send payment by Paypal to BJG145@......"

(...just kidding. Then again...)

Oh... You must have a background in marketing!


1 person likes this

I've been flipping through some of the old versions to see if there's any new XML. v13 had the quantise options in the save dialog, which adds the "groove" mode 2 you found to the XML. I haven't heard anything groovy yet.   


image

 

One of the improvements for Orba 2 is bar length from 8 to 128. According to the change log, "Limit max loop length to 8 bars" was new to v13.18 but I haven't seen how to increase it in v13 yet. There's "nBars" in the app code and the XML.

This UI suggests that quantize was once global but they are converting it to "per-part" which is better.. Drums usually always benefit from being quantized but a lead can sometimes have quick notes or slurs which should not be quantized.


1 person likes this

@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

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

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.

Login or Signup to post a comment