(...although, strangely, that works consistently on one of my Orbas but not the other. Can't see any difference between them, but with the second one that manoeuvre just kills the chords.)
I'm not sure how that works either.. I've tried:
<TuningEntry key="C" name="Custom" intervals="P1, M2, M3, P4, P5, M6, M7, P8"
to see if that would make the Orba grab those intervals. The Fiddler and Editor should probably strip "Pentatonic" from the file because that alters the root notes for each pad. It applies the chord offsets to the Pentatonic versions of the Major/Minor scales.
I've been curious what those "Seekers" actually do. I've found I can move a Chord voice into the Leads folder and it will take the synth settings from the previous voice. For example, I think I copied 1981 from Chords to Leads and renamed it 1981_2. I then loaded the "Faux" sound from Leads and then the 1981_2 sound right after. I believe it kept the Faux sound but added the Chords as described in 1981.
mode and synthMode seem to have something to do with the sound being used when you switch a preset from one folder to another.
<SoundPreset name="">
<SynthPatch mode="Lead" synthMode="0"
Some XML comparisons
Everything generally has a set of <ModifierEntry> containing:
modifierData
modifierUuid
gestureUuid
uuid
...and a set of <SeekerEntry> containing:
seekerData
seekerUuid
uuid
We've only got a result from the first entry in the mofidier list so far; we don't know why there are several, but for now I'm just looking at the first one across three presets ("All Out", "Cartridge", "Lead").
We know that modifierData controls chords. We don't know what seekerData does, if anything, but copying seekerData entries from chord files to lead ones causes the Lead button to play chords. (At least it does on one of my Orbas, but not the other; can other people recreate that?)
The Uuids (identifiers?) sound as if they might be used as keys to match up different data keys perhaps.
So far I've noticed the following:
1) The Seeker uuid always matches the Modifier uuid within a preset. The values change between preset types (eg Drums/Bass/Chords). When comparing different presets of the same type, the values sometimes vary, sometimes not. Eg it's the same for "Cartridge Lead" and "Ohm Lead", but different for "All Out Lead". Ditto for bass. All the Drum ones are the same, and all the Chord ones are different.
I'm not sure if the actual value matters, or whether it's just a lookup key. I suspect that presets may contain data that's not actually relevant for the type, so the fact that they vary across Chord presets but not Drum presets might be a clue that the Seeker keys are only relevant for chords.(?)
2) The value of modifierUuid is the same across all three presets for Lead/Drums/Bass. The chords have a different value, which is the same across all three chord presets.
3) The value of seekerData follows the same pattern as modifierUuid; the chords all have one value, everything else has another.
4) The value of gestureUuid is the same everywhere
It looks it looks as though these Modifier/Seeker keys have special relevance for the Chord type.
Based on the above, I thought I'd test a theory that the 7th chords preset would have a different "seekerData" value to the others, but it matches all the above.
*************************************************************************************************
Looking at the 7th chords file, it's noticeable that the first <ModifierEntry> in the list has the different modifierData info we've identified as chord data, but everything else in that list looks 'blank' by comparison.
Wit the <SeekerEntry> list, it's the opposite; the seekerData value for the first entry looks like the blank template seen everywhere else, whereas everything else in the list is different.
So, we're back to the mystery of why there's a list of values, what the other ones do if anything, because they seemed to have had no effect when we were first untangling the chord data.
With the remaining entries in these lists, the two "uuids" continue to match; I'm sure it's just a cross-reference, so every ModifierEntry has a corresponding SeekerEntry.
I think it's also worth investigating the Song files to try and shed some light on this. These have a section for for each preset type. I'm not sure if the preset files are used when loading a song file...? Would be simplke to test that. It's odd that the data in the preset files doesn't closely match the data in the corresponding section of the song file.
But I think there's probably a lot of stuff that just isn't needed; for instance, each section in the "Song" file has a "quantisation" setting. Sore point, I know, and it doesn't seem to do anything. I expect parts of the code are redundant; inactive, but there may be undiscovered sections that could bring features like the custom chords to life.
>Just pushed up a first crack at the Editor into a separate branch
Thanks @Subskybox, just taking a look. I'm not sure what's meant to happen when you click the "Download" button...tried Edge/Chrome but I don't think it's doing anything. I can't find the file in the Downloads folder.
...love the way it automatically changes from chords to lead when you change the mode on the Orba...
...Seeker observations continued...
I was was still able to load a Song after renaming the associated Preset subfolders, and it seemd to make no difference. So, I think the Presets are just for separating out the different parts of the Song to enable mix & match...? But confusingly the Modifier/Seeker sections are quite different. The Song versions are much more streamlined, and I suspect the additional stuff in the Preset files has no purpose.
For instance, in the Lead preset for "All Out", there are nine Modifier entries with matched Seeker entries. But in the Lead section of the Song file, the modifier list is empty. The nine Seeker entries are still there, but are they actually doing anything...?
The other Lead and Bass examples followed the same pattern.
For the Drum presets, these have a shorter list of four matched Modifier/Seeker entries. But again, if you look at the relevant section of the Song file, the Modifier list is blank.
The Chord preset files have a list of eight matched Modifier/Seeker entries. As usual, the relevant section of the Song file still has all the same Seeker entries, but this time, the Modifier list has a single entry - the one that we've found actually makes a difference if you change it in the preset file.
Based on this, my theory is that the first Modifier and Seeker entry in the Chord preset files (and the corresponding section of the Song files) have an effect. But I don't think the rest of the list for the Chords does anything, and I don't think it's relevant for anything except chords.
It's interesting that to change sounds, you need to load a preset, but you can change the key on the fly via the App. It's sending some kind of data directly/immediately. I was wondering if it might be possible to somehow access the file system on the ESP32 and read/change data on the Orba directly.
https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf
I'm still trying to get the computer to talk directly to the ESP32. I'm interested in seeing whether I can flash it with some completely different program and then restore the original firmware again. There's a couple of different varieties of the card which need different drivers and I'm tempted to take "Orba hacking" literally by opening it up to check the electronics, but I haven't quite reached that stage yet. Maybe soon though if I can't get it working. :-)
>I'm not sure what's meant to happen when you click the "Download" button...tried Edge/Chrome but I don't think it's doing anything. I can't find the file in the Downloads folder.
PS When clicking the "Download" button I get the warning about choosing a starting preset first, whch works, so those buttons are live and triggering the relevant Javascript; it's just that the download process doesn't seem to activate (or I don't understand what it's doing).
@Subskybox
"BTW, the new Editor doesn't require the use of any Daemon anymore :)"
Nice!
A few songs to jam along and the editor make for me the difference between a paperweight and an interesting device (a basic midifile im/export is something I would like very much, but that may be asking too much ;-)). Thank you very much for your efforts!
I've found that by connecting the Orba in DFU mode and running "dfu-util -l" from the UpdateUtilities folder, you can get the following info:
Found DFU: [0483:df11] ver=2200, devnum=3, cfg=1, intf=0, path="3-1.4", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="STM32FxSTM32"
Found DFU: [0483:df11] ver=2200, devnum=3, cfg=1, intf=0, path="3-1.4", alt=2, name="@OTP Memory /0x1FF07800/01*528e", serial="STM32FxSTM32"
Found DFU: [0483:df11] ver=2200, devnum=3, cfg=1, intf=0, path="3-1.4", alt=1, name="@Option Bytes /0x1FFF0000/01*048 e", serial="STM32FxSTM32"
Found DFU: [0483:df11] ver=2200, devnum=3, cfg=1, intf=0, path="3-1.4", alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*64Kg,03*128Kg", serial="STM32FxSTM32"
*******************************************************************************************
This page lists various models like STM32F2, STM32F4, STM32L5 etc.
https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html
Considering this page, which talks about "Programming STM32Fx and STM32Lx Option Bytes"...
https://www.pemicro.com/blog/index.cfm?post_id=170
...I guess this means that the Orba is based on one of the STM32F series boards.
I suppose the last means that it has:
4 x 16K
1 x 64K
3 x 128K
= 512KB...?
COnnecting to the main card, I can still boot it in DFU mode and flash the firmware, but it won't boot now; just flashes the LEDs. Not very surprising. Possibly it wants battery/speaker connections to boot, or maybe I damaged it. I'll carry on tinkering with it a bit.
I'm interested in the layout of the sensor board, which seems to be capacitive-touch based; the folder:
C:\Users\<username>\AppData\Roaming\Artiphon\Orba\UpdateUtilities\capsense
...contains a file called: "orba_capsense_bootloader". I'm familiar with simple touch-on/off capacitive touch, but I'm curious about how the Orba is able to detect finger movements aropund the pad.
Hi Rusty - the Orba is controlled entirely by an on/off button beside a rocker buttons on the pad, by touching eight sensitive triangular areas around its circular top together with a central button, and by various "gestures" which involve eg shaking or turning the device.
I think the hardware is actually quite cool; I still like it, and I think it would be quite possible for a blind person to play and enjoy using the hardware. I can't really talk about how accessible the software is, which allows you to change sounds, etc., as I don't know what's involved in that.
As far as playing the hardware goes, you may find you can orientate your fingers relative to the controls on the side, or perhaps put physical markers around the edge if that helped.
It makes an excellent wireless MIDI controller for use with software like Ableton Live, so if you have an accessible DAW music program on your computer that can work with MIDI controllers that could be another option.
Hey @BJG145 I feel bad cluttering up this thread.
I'm going to start another thread. :)
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
28 people like this idea