Artiphon

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

If you've added some custom scales (e.g. Hang Drum + Whole Tone) can you share up the orba-scales.json file? I can merge it in later... I have a few scales I'd like to add but too interested in figuring out the gesture mapping. How does the SeekerData bind a gesture with a control? I'm thinking index 1 because its unique across all seekerData. Index 0 seems to be gestureType (0 or 1) but one (or more) of those values must link the gesture to the midi message or control # 

Sure here's the patch. On another note, I think I can confirm that Spin Pitchbend will never work. I've been monitoring the midi output from the spin gesture. It sends spin velocity not spin position. I think that video was built before the product was done. You can tell the sound is overdubbed. I think they wanted it to work like that but the esp32 likely did have the "spin" they imagined. It would need a compass to be position, instead it outputs how fast its spinning. Still, it could be useful for changing key or something useful like effect levels.

Quick undecoded seekerUuid comparison from the utility presets. (At the moment I'm basically trying to understand the structure of the Modifier/Seeker pairs in order to try and construct a different one.)

bump / tap / shake note

accc8538-d6cf-4b68-88f2-b99400fad3d1

move / tilt

1cc30432-c214-4c6a-97ab-491975e412d6

spin

2cc30432-c214-4c6a-97ab-491975e412d6

radiate

3cc30432-c214-4c6a-97ab-491975e412d6

shake cc

4cc30432-c214-4c6a-97ab-491975e412d6

press

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

vibrato

6e2b617b-4c1e-4752-96fb-2ac707909aad

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

The fact that bump, tap, and shake note all share the same value seems to make sense; they all do the same thing. They all play a note.

Interesting that move/tilt share a value, then spin, radiate and shake cc all just increment the first character; 1, 2, 3, 4. The rest of the string is shared.

Press and Vibrato are outliers.

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.

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.

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

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

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

Here's the XML for the library definitions in the app code, and a full log from flashing a working Orba from a file.

The Tuning library is the only one that's populated with values; the others look blank. There are some XML tags we haven't seen in the presets such as:

<DevicePreset tuning="Dorian" key="C" />

...from the Preset library.

I guess we could think of the SeekerData from the Tilt Lead preset as Pitchbend, which I've added here.

It follows the same general pattern. It's an effect like Vibrato. This pair have several shared values (63, 29, 76, -128) that set them apart from the others.

...just realised I was getting confused about this "effect" thing. It seems to be a gesture like the others after all...?

I'm not sure how it's supposed to work. Is it a kind of shake...? The notes in Ian's repo say:

<!-- vibrato [pitch wheel] -->

...as if it's a MIDI input or something.

I copied a sample from above:

MemIdx = 0 - MIDI Note at tick 12, channel 1, note 62, duration 496, von 99, voff 85

MemIdx = 8 - MIDI Note at tick 944, channel 1, note 62, duration 464, von 127, voff 87

MemIdx = 16 - MIDI Note at tick 1908, channel 1, note 62, duration 960, von 121, voff 87

MemIdx = 24 - MIDI Note at tick 3845, channel 1, note 62, duration 996, von 117, voff 80

I can see that 16 is a proprietary message for NoteOn. I suspect the next two values define the start tick since two bytes would be required to define a number greater than 255.

Let's look at the tick number 1908. This requires two bytes which I highlighted below:

There is a concept in midi referred to as MSB/LSB (Most Significant Byte / Least Significant Byte). The MSB in the case in binary is a 7 which I saw in often following PlayNote (16). and the LSB is 116. So I suspect that the pattern is

Hopefully I'll get more time this week, but I feel this is very likely what's happening without doing the actual proof.

I haven't decoded them yet, but here's a glance at the ModifierData for the utility presets. All the Metrics have the same pattern, while the Events add a bit of extra data.

Spin

Radiate

Press

Move

Tilt

Vibrato

Pitchbend

AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAABAAEAAA

Shake CC

AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQgAAAAEAAAAAAAAAAABAAEAAA

Bump

AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAACQEAAAAEAAAAAAAAAAABAAEAAA

Shake Note

AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAACgEAAAAEAAAAAAAAAAABAAEAAA

@BJG145 Also I know how long and tedious this is (trial & error, copy/paste, reset device) So THANKS for the hard work. I spent a long time to figure out how the chords worked and if we are going to explore lots of Base64 strings, I might start thinking about a more generic daemon where you can specify the file and the string you want to modify.. In this way you could just make a change and DEPLOY like version 1.. I need to think that out before I commit but that would accelerate the pace of discovery

As a simple example, here's "Tilt Lead Wider" with a value of 20 for a three-semitone bend when the App settings are at 100% scaling, and "Tilt Lead Snap" which lets you hear the result of -20.