Artiphon

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.

"A bad preset either doesn't show up on the Orba or if it does, only causes a problem when one attempts to play it."

It causes a problem when the Orba tries to load it from flash storage into RAM; 'initialise' it.

On Orba 1, you can load a preset, turn it off, turn it on, it loads the preset from flash into RAM, and you can play. If you create a faulty preset by messing with the XML, it will crash and reset when you load it, and start looping, because it's trying to load the same faulty preset and crashes the same way each time. You can fix it by booting from DFU mode and doing a factory restore that resets the presets.

I broke my Orba 2 by opening the partition where the presets are stored and direcly editing the XML of one of them. This puts it into the same kind of loop where it crashes, boots, tries to load the preset into RAM, repeat. But now the storage area where the presets are held can't be restored by any means we've discovered. 

I don't know how you crashed yours, but it presumably started when you loaded a preset that you'd edited.

It's hard to believe that there's no way for Artiphon to recover the device from this state, but they haven't said what it is. If you give up on it entirely it would be interesting to see the PCB.

(I reckon the only way to recover it would be an alternative bootloader that made the data partition accessible without attempting to load a preset. We only have the "run" version of the firmware; we don't have a "diagnostics" version.)

For general reference, the way to access the data partition is to establish a serial connection at 115200 to the Orba using the port shown under the COM ports in Windows device manager and use the command "m". This is what it looks like.

Various other commands available. This is "l".

@BJG145 - Ah, your first comment there makes a lot of sense to me. I'm not entirely sure how I bricked the Orba - I had two breakdowns which I recovered from. (Probably how you just described though.) After the second I couldn't do a firmware update that was being pushed on us, but I could get by, by opting not to try and do it again each time I used the Orba connected. I always deleted the offending preset if I could even if I wasn't sure it was guilty.

The final breakdown left it bricked - possibly, in trying to fix it I did the wrong things and made it worse.

In a way, this brings us back to the factory reset issue - I wouldn't have minded wiping my data partition, that was backed up, and in any case I wouldn't have wanted to restore all the presets I had on it anyway. That bit of housekeeping was due anyway. Wiping that partition seems to be a basic facility we should have available. I can't imagine Artiphon don't have a method for doing that themselves - they must have needed it in development.

As an aside, the new Orba I now have would update to 1_1_13 (which panicked me a bit!), but was fine with 1_1_17 and all seems to be well.

I did pay some attention to your posts about song data although I couldn't quite see what your end aims were. What has struck me, as someone who is really bad at dealing with drums (of any sort), it would be really helpful to be able to create drums patterns  with a step editor. Do you think we know enough to create basic patterns as xml that can be  injected into song presets? (I have only used songs as an easy way of switching keys so far.) That would be useful for me, but could be useful for others who simply want beats looping that they can play over to their hearts content. I don't see Artiphon's approach to songs as particularly viable for many. (And don't get me started on stems!)

...this is only my theory, I don't really know what's going on, but there ought to be a way to recover an Orba 2 from this state that we haven't been told about, and I just tried asking Artiphon again. Re: song data, the only aims were general curiosity in trying to unpick how the Orba represents songs, and seeing whether there might be any mileage in putting ChatGPT on the case. I was encouraged by the possibilities of that, as there's no way I'd ever have been able to translate MIDI files otherwise, and I'm interested in trying it out on other aspects of the Orba 2 but wary of breaking it again.

I've actually only just looked at a stem. I tried some new preset called "KimbraReplay" and realised you can play drum patterns by holding down keys; pretty neat. I'd like to understand how those patterns are built. I haven't looked at the existing threads closely...has there been any progress in figuring that out, and is the current info on it mainly in this thread...?

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:

<SeekerEntry inputLength="Default" inMin="0" inMax="1" outMin="0" outMax="127"
 seekerType="Note" eventSource="Modifier 0 0" noteOffset="0"/>

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

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 :(

...oh, OK, I've just looked at the samples for that song and realised that the sample .wav is the entire drum loop. There's no "pattern data".

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.

"It would be really helpful to be able to create drums patterns  with a step editor. Do you think we know enough to create basic patterns as xml that can be  injected into song presets?"

I haven't looked at loopData for drum patterns. I'll check it out with the safety net of Orba 1 initially. Apart from the quantisation bug they should be transferable.

(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...!)

A little help from devs would be great for this, for sure.

We could achieve much more if it was not that scary to brick O2 irreversibly, and there was a known way to make a full reset :(

At leas at some point  I felt that I should stick to just using custom samples, and never tried messing with parameters outside of the known territory - I mean before any changes to parameters  I always spent time parsing all existing factory presets xml's  to check possible known "safe"  values, which are already used by stock presets. Does not guarantee anything, as there could be wrong combinations of parameters which are in "safe" boundaries of their own, but increases expected life span of O2 - mine is still alive at least.

Looks like  I should have highlighted that in a more explicit way.  (While I do not feel like it would stop David from exploration)

Based on the above, my assumption is that there are several Bezier curves defined. I would guess that one Bezier is defined like this:

[0,0,0,0],[0,0,0,0],

[113,244,40,70],[113,244,40,70],

[113,244,168,70],[113,244,168,70],

[0,254,255,70],[0,254,255,70]

as

[P0x],[P0y],

[P1x],[P1y],

[P2x],[P2y],

[P3x],[P3y]

I'm then going to speculate that each of the 4 integers somehow represent a 32 bit number (likely a float). I'm going to research some different ways of storing these numbers and can hopefully find the right schema. I feel like I'm on the right trail.

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.

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

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

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.