Artiphon

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

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

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.

Here's the serial log for the above test I called "DPC". 

* * * * *

I've found that the "coarse" setting for timing (3rd value in each note block) moves the note and subsequent notes around by a quaver when you increment/decrement it, so note timing is relative rather than measured on a clock that runs for the duration of the loop. 

The "fine" setting will take a bit more experimenting; I think it's basically an offset like with duration, but there's a complication around the overall timing of the loop.

I'm just trying to absorb some of the MIDI programming info. 

When experimenting with duration and then timing, I got the idea that one of the values represented a count of an eighth of the bar, ie a quaver, and the other value was a +ve/-ve offset from that.

With duration, this seemed to work, and I was able to get fixed length notes by counting quavers and zeroing offsets.

With timing, the "fine" control got more complicated. At one point the loop lost a note or two and started playing at double speed. I also found that even if notes were playing back accurately on the metronome, there was still an offset. With one loop I also found that the first note got moved to the end again. I'm wondering if maybe this happens if the first "trigger" note that starts the recording is played fractionlly behind the beat.

I was also thinking that there was something different about the timing values for the first note in the list, and possibly the last. The data for these two might represent something different. Perhaps there are tick values at the start and ending but the middle values are relative, or something. 

The tempo change was strange; the loop was still counting the same length round the dial but it was mostly squashed into the first half, followed by silence. Perhaps there might be some kind of calculation going on between the timing values for the start and finish to work out what the time signature is.

The next thing I was going to try was playing a loop in time, then moving the offsets for notes in the middle of the loop around slightly to see the result.

...great work @Subskybox, and thanks for the explanations. It'll take me a little while to understand it all. In the meantime, I've been taking another look at the "q" quantisation mode in the console, and it does actually seem to work. It doesn't change the data in the Orba; just the playback. "q" turns all four channels on and off at once, but I'll do some experimenting with the quantisation mode tags in the XML files and see if they do anything. I also need to experiment to see what might turn quantisation off again when it's been switched on in the console; eg power off, new song, etc. 

Here's a demo of a quantised loop. It was recorded with some notes slightly out; eg the third note from the end is fractionally late. It plays twice. Then there's a gap, and the quantised version plays twice.

Thanks! Did you post the DPC header info in CSV? I think its going to be important to map those. I think its 18 bytes and will somehow line up with the serial log header info. What I'm most interested in at the moment is beatLengthTicks and quantStartSnapTicks. In the DPC example, these are 480 and 120. So I'm thinking this 1/16 note quantization. To make it more obvious, I think we could change the 120 to 240 or even 480. This would snap all notes to 1/8 notes or even 1/4 notes. This would be great to make sure this is configurable and to make absolutely sure that quantize is working. I'm also wondering if the developers left a secret way in the Orba app to flip the quantize setting. :) 

>"I'm thinking this 1/16 note quantization. To make it more obvious, I think we could change the 120 to 240 or even 480. This would snap all notes to 1/8 notes or even 1/4 notes. This would be great to make sure this is configurable and to make absolutely sure that quantize is working."

Here's another quick example; at this tempo the quantise only works on very small errors, much more than this and beats start moving. Yes, will be interesting to try and change the snap settings... 

If you change the Tempo does it change the beatLengthTicks value? 

...not as far as I can tell; I tried playing a song at 120 and 60 and the data looked the same. (Attached.)

I can't find the loop info parameters anywhere except in 0x8000000.bin, where they look like this:

   Looper Configuration:

   loopBarEndTolerance: %u

   beatLengthTicks: %u

   notesPerBar: %u

   quantMode: %u

   quantStartSnapTicks: %u

   quantBarEndSnapTicks: %u

   allowRecordingSilenceStart: %u

   allowRecordingSilenceEnd: %u

   thinnerMode: %u

   cc_error_limit: %lu

   pbend_error_limit: %lu

   ccA: %u

   ccB: %u

   ccC: %u

   thickenerMode: %u

   thickenerEmitPrd: %u

   thickenerMaxDt: %u

   noteStartWindow: %u

The Orba.exe app starts with:

quantStartSnapTiMZ

...as the first data, and that's about it.

...I've tried adding stuff like:

    <SynthPatch mode="Lead" quantizationMode="1" loopBarEndTolerance="2" quantStartSnapTicks="2"

                quantizationStartSnapTicks="2" ccA="2" thinnerMode="2" allowRecordingSilenceEnd="2"

...to the presets, though that XML doesn't actually appear anywhere, but it doesn't seem to have any effect. I suspect that running the App may turn quantisation off again, though I think it survives power-off.