Artiphon

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

Hi folks, I'm afraid I don't have much to contribute to the hacking  part of this thread, but I am reading in idol curiosity.

I am hoping that what you have been able to discover will help me in using my orba2 when I get it.

I happen to be blind. My interaction with computers and phones is with screen readers. But Artiphon has not yet, and makes no promises, to implement any accessibility in to their apps though they do use JUCE which has embraced accessibility in it's more recent versions.

Anyway, as we know, the Orba is cool, but the software opens up the possibilities to change keys and sounds and other stuff.

So, I'm wondering how you hackers may be able to help make Orba more accessible. Any chance that accessibility may be considered in the software you are putting together?

Generally things are accessible if the conventional navigation and control  features of the OS are observed. Things get less accessible when custom UI features are used.

So, any thoughts for this blind musician hoping to exploit the Orba in my music making journey? :)

thanks!

These table might help:

Voice Message           Status Byte      Data Byte1          Data Byte2
-------------           -----------   -----------------   -----------------
Note off                      8x      Key number          Note Off velocity
Note on                       9x      Key number          Note on velocity
Polyphonic Key Pressure       Ax      Key number          Amount of pressure
Control Change                Bx      Controller number   Controller value
Program Change                Cx      Program number      None
Channel Pressure              Dx      Pressure value      None            
Pitch Bend                    Ex      MSB                 LSB

The first nibble of each byte is the type. So NoteOn in hex is 9x and NoteOff is 8x. Note On will be a decimal value of 144-159 because channel is the second nibble. NoteOff will be 128-143. This is the midi standard. To be more precise.. here is that section of the code from the Editor:

switch (command) {
        case 153: //DrumOn
        case 152: //BassOn
        case 159: //ChordOn
        case 144: //LeadOn

        case 137: //DrumOff
        case 136: //BassOff
        case 143: //ChordOff
        case 128: //LeadOff

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.

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

If you edit the Orba application in Notepad++ and search for text parameters from the XML like "RetainNotes", you can find alternatives that I haven't seen in the XML, like "RetainIntervals".

 A typical tuning entry looks like this:

  <TuningEntry key="C" name="Major Pentatonic" intervals="P1, M2, M3, P5, M6, P8, M9, M10"

               midiOctave="3" transpositionType="RetainNotes" type="tonal" tuning="60, 62, 64, 67, 69, 72, 74, 76"/>

So far we haven't found any result from changing the "intervals" list, only the "tuning" values. I think that may be because the transpositionType is set to "RetainNotes", but if you change it to the alternative "RetainIntervals" value found in the App code, I reckon that's where the "intervals" string might start changing things.

I reckon it might be something to do with the way the chord sequence change when you change key in the App. I got some different result from it at one point, but couldn't then recreate it.

It might be worth scouring the code for other parameter values like this that we don't know about.

I also had a scour of the application itself and found lots of xml. Here is a sample:

  <TuningList category="percussion" keySelection="false">
    <TuningEntry name="All Kicks" />
    <TuningEntry name="Drum Kit" />
    <TuningEntry name="Electro Kit" />
  </TuningList>
  <TuningList category="tonal" keySelection="true">
      <TuningEntry name="Major"            type="tonal" intervals="P1, M2, M3, P4, P5, M6, M7, P8" />
      <TuningEntry name="Natural Minor"    type="tonal" intervals="P1, M2, m3, P4, P5, m6, m7, P8" />
      <TuningEntry name="Harmonic Minor"   type="tonal" intervals="P1, M2, m3, P4, P5, m6, M7, P8" />
      <TuningEntry name="Melodic Minor"    type="tonal" intervals="P1, M2, m3, P4, P5, M6, M7, P8" />
      <TuningEntry name="Major Pentatonic" type="tonal" intervals="P1, M2, M3, P5, M6, P8, M9, M10" />
      <TuningEntry name="Minor Pentatonic" type="tonal" intervals="P1, m3, P4, P5, m7, P8, m10, P11" />
      <!--
      <TuningEntry name="Dorian"     type="tonal" intervals="P1, M2, m3, P4, P5, M6, m7, P8" />
      <TuningEntry name="Phrygian"   type="tonal" intervals="P1, m2, m3, P4, P5, m6, m7, P8" />
      <TuningEntry name="Lydian"     type="tonal" intervals="P1, M2, M3, A4, P5, M6, M7, P8" />
      <TuningEntry name="Mixolydian" type="tonal" intervals="P1, M2, M3, P4, P5, M6, m7, P8" />
      <TuningEntry name="Locrian"    type="tonal" intervals="P1, m2, m3, P4, d5, m6, m7, P8" />
       -->
  </TuningList>

 I also found lots of svg sources which I pasted into html docs. These are mostly UI elements but might lead to clues.. 

This is the kind of data you get in the console if you press keys 1-4 for "Loop info"  while a four-track sequence is playing.

Tilt Lead is quite minimal from an XML perspective, so maybe the Seekers/Modifiers are not totally distinct and there is some overlap?

@BJG145 said: " I don't know if you might have a clearer idea what kind of differences there are...?"

Unfortunately, I don't. I can tell you that this .bin file is likely just a memory dump that can be downloaded/uploaded from/to the device. It definitely contains what I would consider compiled C code. Disassembling compiled C would be almost as cryptic as the bin itself. It might be best to hunt through the bin file looking for any bytes that hold the values 120, 240 or 240. It might be possible to zero in on where the default values are defined. Since this is C, there won't be any indication of variable names so we need to hunt by value rather than by name. There are likely numerous hits if you search for those bytes, but if we're lucky they might appear close together which would be an area of the code where all these variables get initialized. 

Found these nuggets :) These could be very useful..

https://storage.googleapis.com/orba_firmware_updates/appcast_fw.xml

https://storage.googleapis.com/orba_software_updates/appcast_beta.xml

Adding these to check for correlations.. @BJG145 Are Radiate & Bump really both Index 9?

From the Orba Manual: