Artiphon

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

...actually, the console quantization setting seems to stick through song changes and power cycles. Once it's on, it stays on. I haven't been able to change the value of it in the XML yet. I'm not sure how useful it is without being able to change the parameters, but it's worth knowing about. I'll be interested to see how it's implemented in Orba 2.

I don't think that would work since those appear to be channel level settings. Do you have the eventData that matches the log (Channel 1)?

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

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.

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

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

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

@BJG145 Hoping you have Excel.. Here is a spreadsheet (with formulas which completely validates the 8-byte note structure)

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

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

Wow.

Okay I've got it figured out :) Let's use DPC as the example. BeatLengthTicks = 480, so 480 ticks per quarter note. The correct 8 byte sequence is:

1. Command (16 is PlayNote but there are likely other for CC values etc..)
2. Relative Start Tick [LSB] since last (event or note unknown)
3. Relative Start Tick [MSB]
   
4. MIDI Note #
5. Velocity ON (1-127 follows 7 bit MIDI standard)
6. Velocity OFF (1-127 follows 7 bit MIDI standard)
7. Duration in Ticks [LSB]
8. Duration in Ticks [MSB]

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.

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