Start a new topic

Orba hacking knowledge base

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

27 people like this idea

I've just had a look at the csv file from the latest test.. I don't think MIDI is important here now that I see the data. Does the device emit midi when you play back a song.. Actually I think I already know the answer is yes. I have a guess at what the pattern is now that I see your csv. I just need to go test my theory...

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


1 person likes this


1) Changing those 7s to 20s made a mess of the sequence with several notes playing at once

2) Changing the "coarse durations" to 4 made all the note last about 3 clicks

3) Changing the last two values of every block of 8 ("fine/coarse") to 0,4 made every note exactly two clicks

MP3 attached showing before/after this "manual duration quantise". (Ignore the bass note; pressed that by accident.)

The "coarse" value for duration probably rounds to the nearest number of quavers and the "fine" value is an offset to lengthen or shorten it, or something like that. 

 So for each block of eight values that makes up a note, we have:

1) Play note command. (Probably. Can confirm when we get on to the CCs.)

2) Timing 1...?

3) Timing 2...?

4) Note

5) Attack

6) Release

7) Duration - coarse

8) Duration - fine

That just leaves timing...


Looking at the eventData for the last test, it's interesting that every note value is preceded by a 7, except the first one. That makes me think the theory above isn't quite right.

Re: the "Fine/Coarse" duration control, I haven't fully thought this through, but I'm imagining that there's a "coarse" value that counts whole clicks, and a "fine" value that counts the offset within the final click; or something like that. 

The start-time data could work in a similar way; one value that counts the number of clicks from the start, and another that counts the offset within the final click. Just a theory so far.

...the results are in. This next test is called DPC or Duration Pitch Change. The files are simply:

1) MP3

2) MidiOx screen grab

3) eventData

This test has seven ascending notes:

1) 1/2 are one click long

2) 3/4 are two clicks long

3) 5/6 are one click long 

2) 7 is short

I was main interested in:

1) Whether the first note of the data is the first note of the sequence, and doesn't get bumped to the end. (Previous "Loop Info" console logs had left me wondering. But it's fine, it's in simple order.)

2) Whether the value I've described as "duration-related" would go up and down again. It does. It goes 1, 1, 3, 3, 1, 1. I'm still not sure exactly what it's for, but this is in line with previous results. It seems to be some kind of indicator of duration rounded to the nearest number of clicks.

I'm currently wondering whether the two values following "release velocity" might represent duration as a kind of "fine/coarse" control. That would leave the last two unknowns ( preceding note value) as "fine/coarse" for start-time. 

I think start-time is probably absolute rather than relative, for a couple of reasons; partly because that would fit with the Memidx console info, and partly because when I tried to add a bunch of notes to the sequence in a simple way (by copying and pasting the string data multiple times), they all played at once. 

(595 Bytes)
(591 KB)

There are different ways of measuring time. You can say, "Start at X, and end at Y". Or you could say, "Start at X, for duration Z".

I was starting to wonder whether the timings in eventData were absolute or relative. It looks as though each note event is a block of 8 values from the beginning of the list, with no header.

1)  16 (Tap note command?)

2)  +ve and -ve (?)

3)  Low +ve (?)

4)  Note value

5)  Attack velocity

6)  Release velocity

7) -ve (?)

8) Low +ve

I was looking at the "Memidex" list in console, which also shows blocks of 8...

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

...and remembered the tip from @Subskybox.

I suspect [eventData] is exact same data from the MemIdx does look like it. The next question is working out what order it's in. Need to test durations that get longer and then shorter again...

I forgot to include the LoopData in the "Lead Test" .csv posted previously (which looked at different simple patterns of repeated notes). Here's an updated version with this added.


>"The Orba data has a 0 which I think may represent the Note On event, followed by MIDI note"


I've also realsed that these "0" values are what I called "Duration" in the next test I posted, which looked a durations of 1, 2 and 3 clicks. The value in those were 1, 3 and 5 respectively. In the "Lead test" the notes were very short taps resulting in a 0 value.

I've relabelled them as "Duration-related"; not sure exactly what they represent yet. 


Every note value (62=D4) has a value of 16 three places before it, with the first 16 being the start of the data. Perhaps this represents the "Play a note" event or the MIDI channel number. It looks like eventData bundles note-on and note-off into a single entry which includes timing, note, duration, attack velocity and release velocity...?

Just to clarify the timing of the performance:

click - on

click - off

click - on

click - off

click - on


click - off


click - on


click - off


click - on



click - off

click - on



click - off

Here are some files from a duration/timing test. There's an MP3 of the loop, and a CSV giving data from:

1) MidiOx MIDI monitor (from Orba's USB/MIDI)

2) loopData

3) Decoded eventData

4) Console data (with extra final note in order to generate the report)

The loop is all on one note, and consists of:

1) Two notes with duration of 1 click, separation of 1 click

2) Two notes with duration of 2 clicks, separation of 2 clicks

3) Two notes with duration of 3 clicks, separation of 1 click

Looking at eventData, there's an unknown negative value after release velocity. This is followed by a value that's 1 for the first two notes, 3 for the second two notes, and 5 for the last two, so it looks like that's related to duration. 


PS all notes were played as a quick tap

1 person likes this

Sequences are:

1) Lowest note

2) Second note

3) Third note

4) Two notes (loud)

5) Two notes (soft loud)

6) Four notes at double speed. (The others were on the beat.)

1 person likes this

Here's a CSV file showing various logs from different simple lead sequences. I've been using a MIDI event log viewer called MidiOx to check the Orba is sending, and cross-referencing these against eventData. This logs hex; I've indicaed where I've lef that untranslated.

The Orba data has a 0 which I think may represent the Note On event, followed by MIDI note, attack velocity, and release velocity (I think). There's then a few values which are going to represent duration and timing data. Need to do some more tests to establish the pattern here.

(2.64 KB)

1 person likes this

Just some notes on workflow...

I've now been abloe to record a set of songs with tap-only data. The method is:

1) Load 1981 and quit the app

2) Create a copy of the 1981 Lead preset with tap only (first Seeker/Modifier only) and Major scale

3) Record a sequence

4) Run the app and quit it again, saving the song

5) Make a copy of the new song file version the App has created and give it a suitable name

6) Clear the sequence and repeat from (3)

Usually the App makes successive copies a song as you record new sequences, but after feeding it a tap-only Lead preset I couldn't get it to go beyond the first one.


I've found that the console event list posted above shows live events while recording; I don't think you can get that view during playback.

The Looper info logs (1-4 in consoel) are a bit strange. If you record with sequences in the console, they get populated, but if you load a song containing event data, they don't. However, if you record another note on the end, then that shows up, and the previous data shows up too.

The Looper info log for this song that you're extending displays in a "live" readout kind of way; if you keep tapping the relevant number for that loop (Bass/Lead/Chord/Drums) whie it's playing, it shows all the info up to that point. 

So to recap, to get the console Looper info from a song you've loaded from the App, you need to:

1) Quit the App

2) Turn the Orba off and on again

3) Connect via eg Putty

4) Put the Orba in Record mode

5) Add another note to the sequence you've recorded

6) Tap the relevant loop button (1-4) just as the loop ends  

Login or Signup to post a comment