Artiphon

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

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

PS all notes were played as a quick tap

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. 

Just to clarify the timing of the performance:

click - on

click - off

click - on

click - off

click - on

click

click - off

click

click - on

click

click - off

click

click - on

click

click

click - off

click - on

click

click

click - off

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

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. 

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

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

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

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.

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.

Experiments:

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

3) Timing 2...?

4) Note

5) Attack

6) Release

7) Duration - coarse

8) Duration - fine

That just leaves timing...

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

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

What I really need is the serial log that matches the csv. I'm going to attempt to predict the log output.

I copied a sample from above:

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

I can see that 16 is a proprietary message for NoteOn. I suspect the next two values define the start tick since two bytes would be required to define a number greater than 255.

Let's look at the tick number 1908. This requires two bytes which I highlighted below:

There is a concept in midi referred to as MSB/LSB (Most Significant Byte / Least Significant Byte). The MSB in the case in binary is a 7 which I saw in often following PlayNote (16). and the LSB is 116. So I suspect that the pattern is

Hopefully I'll get more time this week, but I feel this is very likely what's happening without doing the actual proof.