Orba 2 Hacking Knowledge Base : Artiphon

Subskybox

started a topic over 1 year ago

This forum is intended to share Orba 2 hacking tips amongst the Orba 2 community. NOTE: Please post facts that are well understood & useful. If you have theories to discuss, please start another forum and link to it here.

D

David Benton

said over 1 year ago

I have noticed some issues relating to pitch (or tuning) on the Orba (both 1 and 2).

I have been trying to make a sample based lead preset (a process more involved than I had anticipated).

I used a couple of different presets as examples for file names etc. and I noticed that the pitches in the parameters of some were not consistent with regard to octaves - this is understandable as some instruments are notated in a different octave to the one they actually or perceived as in. The guitar is one example of this. And, of course, transposing instruments like most (all?) brass instruments are also written in different pitches than they sound - but I guess those familiar with that compensate.

Some presets have been made to play in a particular key which may also add complications.

But I also realised on one patch in particular that they seemed not to be in concert pitch - the tell tale indication was that there were no notes at A440 (concert pitch standard), A880 (the octave above) or A220.

I recall there has been come concern that bass presets were sometimes out of tune with chords and/or leads. I think the problem here may be that presets made in sets may not be compatible with presets from other sets if they were made in different pitches. That might happen for a variety of reasons, but what it means is that mixing presets from different sets may clash in regard to pitch.

I'm not familiar about how the Orbas handle pitch with samples so perhaps the problems come from how the Orba handles them, but it might be down to how the samples are made and described in a preset.

D

David Benton

said over 1 year ago

Seems I was wrong about the global reverb and chorus being a fourth group in the mod section. These are dealt with in other synthPatch settings. At the moment my best guess is that the fourth group is currently redundant - perhaps it's just there for possible future use?

D

David Benton

said over 1 year ago

I should have added that the other synthPatch settings seem to correlate to the various settings you can make in OrbaSynth but since they are labelled and ordered differently it can be a bit hard to work out what exactly matches what - I've been trying and I'm not certain about some.

D

David Benton

said over 1 year ago

I think I have come to some understanding of the seekers and the mod entries in the synth patch.

All of this is pure guessing, speculation and hopefully enough logic to make sense. So none of this should be considered to the truly accurate.

The mod entries in the synthPatch relate to the three allowed "effects" for each gesture - which is done by altering parameters in the patch on the go. However, there are 4 main groups of mod entries. The fourth group relates to the global chorus and reverb effects and so don't count as part of the three allowed. Whether this group comes first ie: modSource1, or last ie: modSource4, I'm not certain.( I suspect the existence of a 1_2 etc. or 4_2, whichever, is sometimes redundant.)

The format of these entries is modSource1_1. The first number, I have already covered, the second possibly relates to the Oscillator (1 or 2) and 3 relates to VCA or LFO. Someone who understands synth programming may be able to clarify that last idea. The destination parameters I think relate to the various options listed in the dropdown menu in the Gesture Mapping section of the Orbasynth app. Weight hopefully is obvious - how much it affects the chosen parameter.

Seekers relate simply to the collection of data from sensors and translating the data to the programs functions.

My theory is that inMax and inMin entries relate to data that is coming in (obviously). Whether they define the limits it accepts, or the limits of what it will act on, I don't know. I can see some use of the latter.

outMin and outMax is what the incoming values are translated to for the program to use. Again these limits might define what values can be used by the program or if values are outside that limit they can be adjusted or ignored.

The "seekerType" seems a simple intruction - either seek for Note (the keyboard presses) or Controller (the motion sensors) data. The "controller" parameter remains unclear to me. The mix of numbers and "Pitch Bend" in text in the parameters is understandable perhaps, but Aftertouch in there mystifies me a bit.

In "eventSource", Default Note Source, is presumably the keys - what the "Secondary Note Source" is I don't know - perhaps it's a bump (and/or shake?) which have to be handled differently. (This seems a bit confusing because it sort of duplicates "seekerType". Perhaps seekerType calls an action to collect the data, while eventSource defines how it is used when received.

"triggerSource" and "triggerRule" set what will get the effect going - ie: it could be as soon as a key is pressed, or only when gesture data is incoming, or a gesture indicates that the effect should start.

The "metricSensor" is simply whether data is from the keys or the motion sensor. Perhaps it's just a flag for the program.

"metricSelection" is what set of data is to be exported and relates it to midi usage. However this is for both the Orba itself as well as midi signals to other devices. Since "Shake" doesn't have a midi equivalent this would explain the mismatch in the parameters format. MPE X and Y are like graph axis on the key surface, Z is tilt. (Somehow this doesn't seem quite as certain now than it seemed when I first thought it up.)

"maxRate" I think is about how frequently the sensors are polled. Whether this is a timing such as 20 milliseconds apart or 20 times per second I don't know. I think, however, it may be important as it may force the device to try and process more than it handle, causing glitches in the sound output - hence the need for different values for some situations.

The reason you can't get an effect without both the mod and seeker settings is because if you don't use the data incoming you ain't gonna get the required output.

As ever ,I hope this helps and apologise if it's already known.

Subskybox

said over 1 year ago

@Artiphon @BJG145

Orba 2 should always be recoverable as mentioned above.. However, it is not as BJG145 points out (he even has a video of the boot loop the device is stuck in). I would encourage Artiphon to examine the device that BJG145 is/has sending/sent back. Perhaps changes to future firmware could be made to prevent this from happening.

Arne Wallbrecher

said over 1 year ago

If you connect to a desktop computer via USB and open the Orba 2 app, it likely will restore your Orba 2.

BJG145

said over 1 year ago

Orba 1 was always recoverable, so you could try all kinds of random experiments secure in the knowledge that a reset would sort it out. With Orba 2, unfortunately, that ain't so, unless we can find a new way to access the data partition.

BJG145

said over 1 year ago

You may be right; trying to remember but I think a lot of the Modifier stuff in the Orba 1 XML maybe didn't do a lot. As far as I remember, the Seeker lists represented a bunch of different stuff, starting with the basic event of playing a note, and proceeding through various types of expression/movement such as tilt etc. IIRC the first Modifier entry in chord presets held the data that encoded the chords, via a system that @Subskybox figured out.

Last time I was looking at the Orba 2, back in November, @Subskybox had pointed out that you couldn't play two different chords at once in the same way that you could play two different lead notes at once and I was investigating that. Then it all went pear-shaped.

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

>"Chords seem to be monophonic"

I was just looking at this. The first SeekerEntry for lead sounds, eg 1981, is:

<SeekerEntry inputLength="Default" inMin="0" inMax="1" outMin="0" outMax="127"

seekerType="Note" eventSource="Default Note Source" noteOffset="0"/>

For chord sounds, it's:

This seeker seems to define aspects of the basic "play note when you tap" event. They're identical except for the eventSource value in the second line. I just tried editing the "Default Note Source" value from a lead preset into the Berimbau chord preset, on both the PC and the Orba. The result is a regular scale which can be played polyphonically under the "Chord" section on the Orba, but it's only single notes. Dunno whether this has any use but I thought I'd mention it. It might be worth looking into the effect of "Modifier 0 0" and see what other values do.

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

...oops...tried another random change with "Modifier 5 5" and now I can't start it up; just coloured lights and a reboot loop.

D

David Benton

said over 1 year ago

The ModifierEntry lists seem to be unnecessary. I have been trying to create a template for making Orba 2 presets. I have resorted to using a few seeker entry sets that I know are "safe" and choosing (by trial and error) which ones work as I hope with the synthPatch I'm working on. Altering parameters as little as I can. For the moment this seems the best way (for me, at least) to go. The problem with that is that it's hard to understand what each ones does and how it will work with different patches - so it's far from ideal.

But the knowledge you guys are bringing help in understanding it all. I will try and add the little crumbs I find to it as I can.

BJG145

said over 1 year ago

(PS I share your pain at not being able to edit posts; I must be more careful in future or I'll end up endlessly deleting them and re-posting them to fix typos like in the old days...can't be bothered with that...!)

BJG145

said over 1 year ago

I'd be happy to get back into rambling discussions about this thing, but I know that @SUbskybox was originally hoping to keep this thread fairly focussed so I don't know if I should start another thread for background conversarion, but just a bit more on this while I'm waiting for my new Orba 2...

The Orba 1 experiments were a long time ago and it's going to take me a while to catch up on what you've discovered about the Orba 2. But firstly, DFU mode...I'm not sure that the Orba 2 has what could strictly be called DFU mode, or not one we've found out how to access...? (I don't have any expert knowledge of this stuff.)

It was possible to boot the Orba 1 into a mode where it could be recognised as a DFU device by dfu-util IIRC, but the 'bootloader' mode on Orba 2 seems to work differently. It's not seen as a DFU device. Instead, the Vol/Power startup makes a bootloader partition available. The device also has a secondary "fallback" bootloader partition, and a data partition.

The mistake I made was to edit a preset as above directly on the data partition. It might be possible to mess it up in the same way by loading a preset; I'm not sure. What I think happened is that the Orba 2 would boot, attempt to load the default preset, fail/crash, and restart.

You could still use Vol/Power to access one of the bootloader partitions, and after about 16 restarts it would give up and open the other. It was possible to reset/fix these; you could wipe them entirely and the Orba recovery options would rebuild them. However, these utilities don't fix or rebuild the data partition, and there was no way to access that. The only way into it in the first place was via a serial connection and console command, but after it got stuck in the boot loop it was no longer possible to connect to it to send it the command to open the data partition in order to repair it.

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

I was just comparing omne of the old Orba 1 presets with an Orba 2 equivalent. With Orba 1 there were always these matched lists of "SeekerEntry" and "ModifierEntry". We made a little progress with understanding what these did but never fully mapped them out. Orba 2 presets still have the "SeekerEntry" lists, now readable, but not the "ModifierEntry" lists, but I don't know where they've gone; how whatever they did is handled now.

I

Ignis32

said over 1 year ago

Wow, that's serious. Thank you for the warning, that part did not look that intimidating.

Did it not even go to the dfu mode? Theoretically there could be a service firmware that cleans the storage, and it could be nice to be prepared for this scenario, but it is unlikely that we can do that on our own, unless we know the hardware specifics.

At least, seems that ESP32 on board with which I have some experience, is not the main processor, it seems to be only responsible for providing the bluetooth connection. ( esp32 part of the firmware had not changed since fw 1.0.10, ble mac address of Orba2 belongs to the Espressif range, esp32 part of the firmware seems to contain only ble related IDF library strings and nothing else )

Main firmware seems to be the one that is temari_XiP_BEE, it is most probably encrypted and belongs to some nxp microcontroller, and that's beyond my expertise :(

BJG145

said over 1 year ago

It's possible to break the Orba 2 beyond the help of Artiphon tech support by hacking presets. I finally got round to sending mine back for replacement yesterday and look forward to catching up with some of the latest discoveries.

At the time I was messing around with entries like:

...and made a random change to "Modifier 5 5" directly on the device. The result was a boot loop that neither me, Artiphon or @Subskybox could fix.

I

Ignis32

said over 1 year ago

>> wouldn't mess with the Modifier Chains unless you really know what you are doing.

Actually, I guess that's a Vietnam flashback from Orba1, I've looked into presets I have on hand for Orba2 and there are no ModiferChains with modifierdata encoded stuff anymore. Could not find even one.

However we still have these cryptic curves data to be scared by.

Ive found only two unique values for event_curve_assignments_entry.curveAssignmentsData

AQEBAQEBAQEBAQEBAQE=

AQEBAQEBAQEBAQQBAQE=

These mean the following in hex:

0101010101010101010101010101

0101010101010101010104010101

for gesture_curve_assignments_entry.curveAssignmentsData there are 4 unique variants:

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQYGBgYGBgYGAQEFAQEBAQEEAQEBAQE=

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQMDAwMDAwMDAQEFAQEBAQEEAQEBAQE=

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAQEBAQEEAQEBAQE=

AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEEAQEBAQE=

In hex that would be

0105050505050505050101010101010101010101010101010106060606060606060101050101010101040101010101

0105050505050505050101010101010101010101010101010103030303030303030101050101010101040101010101

0105050505050505050101010101010101010101010101010101010101010101010101050101010101040101010101

0101010101010101010101010101010101010101010101010101010101010101010101010101010101040101010101

Bezier curves (bezier_curves_entry.bezierCurvesData ) are much more diverse:

AAAAAAAAAAAbIdtFuHmURkLVY0atYNBGAP7/RgD+/0YAAAAAAAAAAHH0qEajwHVEUt/6Ru1F4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRtDVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGwtWjQ6PA9UbC1SNEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg==

AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEajwHVEUt/6Ru1F4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRtDVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGWDKiQ00x80aspBtEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg==

AAAAAAAAAAAbIdtFMDiURifIY0atYNBGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGWDKiQxt/9UaspBtEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg==

AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg==

AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEaOj21EUt/6Ru1F4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg==

AAAAAAAAAAAbIdtFMDiURifIY0atYNBGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xG0qujQxe69UYNBCNEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg==

AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGWDKiQxe69Ub/LSNEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg==

In hex it would be like:

0000000000000000 1b21db45b8799446 42d56346ad60d046 00feff4600feff46

0000000000000000 71f4a846a3c07544 52dffa46ed45e145 00feff4600feff46

0000000000000000 67981946d0d5a343 7b50384652dffa46 00feff4600feff46

0000000000000000 be279c46c2d5a343 a3c0f546c2d52344 00feff4600fe7f46