chord quantization bug

[mfreer]

It looks like there may be quantization bug when playing chord sequences (firmware v1.1.063).

Steps to reproduce:

1. Set Pad Quantize: Pad Qt: 1/4
2. Create the following Chord Sequence:

Section A, Slot 1:

• 4.0 x 1/4 Notes.
  
• C Major
  
• I C Triad
  

Section A, Slot 2:

• 4.0 x 1/4 Notes.
  
• C Major
  
• IV F Triad
  

3. Record the chord Sequence into an external Midi sequencer (e.g. The Deluge) - ensuring the external sequencer has any record-quantize setting disabled.


Results

• The chords correctly start on the first beat of each bar.
  
• Each chord plays for 1 bar + 1/64th extra, causing an overlap of the chord notes on the first 1/64th of each bar (from bar 2 onwards).
  

If you change the NDLR Pad Quantize setting to either 1/8 or None, then you get a different result:

• The first chord plays for less than one bar (57/64ths).
  
• The second chord starts 7/64ths early, i.e. it begins during the first bar.
  

Thanks

[Darryl]

Thanks for the report. Can someone record this into a DAW and see if the same thing happens?

[Steve]

Thanks for the report!
I was wondering how you come to measure in note duration (i.e. 1/64s) as opposed to time (milli secs). Is it the Deluge?
Thanks,
Steve

[mfreer]

Hi Steve,

The Deluge permits you to change it's grid resolution, with the lowest resolution being 64ths.
So when I record MIDI notes into the Deluge, I'm able to then "zoom-in" and inspect the note lengths by changing the resolution.

Hope that helps

[drGrov]

I had a go at recording the output of the NDLR into Bitwig (I'm more of an out of the box guy, who also happens to own a Deluge ). In all my tests I had the NDLR connected to my Windows PC over USB and Bitwig was the master clock at 60BPM. The chord sequencer was set up to output the same chord every bar (4.0 x 1/4 notes) and I recorded the pad. Pad quantize was set to 1/4 notes on the NDLR.

There were some interesting variations in the timing. 

• The notes in first chord recorded were consistently longer than any subsequent chords. Bitwig seems to display note lengths as bars.quarter.quarter-quarter.fraction down to 1/100th of a 16th note. The first chord length is always > 1 bar (usually 1.0.0.20 or 1/5 of a 16th note longer).
  
  
• Any chords after the first are mostly 0.3.3.98 or 1/50 of a 16th note shorter than a bar. 
  
  
• The start point of each chord after the first would drift backwards from 0.2 16th notes past the start of the bar but then occasional longer chords would push it forwards again so that the start time wandered between 0.1 and 0.2.
  
  
• Whenever I recorded I also saw a 0.27 of a 16th note delay before the first chord started. I'm guessing that this could be latency in my system so I've ignored it for the above.
  

I hope this is useful. These aren't massive numbers (1/5 of a 16th note at 60 BPM is 12.5 milliseconds) but as that's nearly a 1/64th note it may explain why the Deluge displays the first chord as an extra step longer when zoomed in.

[Steve]

Thanks guys for looking more closely at this.
I think the best way is to look at the note events through the logic analyzer. When I get some time I’ll have a look.
BTW each MIDI 3 byte message, including NoteOn and NoteOff = ~1ms (960us = 30 bytes @ 32us/bit).
On a down beat the NDLR can be generating 14 messages (or more): 1 each motif, 1 Drone, 4 pad (x2 on/off), that’s 13.44 ms.
Not to mention the USB latency.
The NDLR message dispatch is pretty simple, at the same time serial MIDI is dog slow compared to typical modern interfaces and this kind of an issue has plagued MIDI controllers since the beginning.
Again thanks for digging into the next level.
Steve

[Steve]

Thanks guys for looking more closely at this. 
I think the best way is to look at the note events through the logic analyzer. When I get some time I’ll have a look.
BTW each MIDI 3 byte message, including NoteOn and NoteOff = ~1ms (960us = 30 bytes @ 32us/bit).
On a down beat the NDLR can be generating 14 messages (or more): 1 each motif, 1 Drone, 4 pad (x2 on/off), that’s 13.44 ms.
Not to mention the USB latency.
The NDLR message dispatch is pretty simple, at the same time serial MIDI is dog slow compared to typical modern interfaces and this kind of an issue has plagued MIDI controllers since the beginning.
Again thanks for digging into the next level.
Steve

 
Just thought of this isolation method. Can an you guys look at this with only pad on and pad = 1 note?
thanks 
Steve

[drGrov]

Just thought of this isolation method. Can an you guys look at this with only pad on and pad = 1 note?
thanks 
Steve

Same result with Bitwig (longer first note, start of all following notes offset from the start of the bar).

My Deluge also showed an additional step for the pad when I recorded it there.

However, I'm now starting to think my DAW results aren't that useful. As a sanity check I tried recording a simple sequence from the Deluge into Bitwig (no NDLR involved) and observed the same  "problems". This is why I went DAWless...

[mfreer]

Just thought of this isolation method. Can an you guys look at this with only pad on and pad = 1 note?
thanks 

I can confirm that configuring the NDLR to use one note, produces the same results when recording into the Deluge, namely:

When using the 1/4 Pad Quantize setting: 

• The chords correctly start on the first beat of each bar.
  
• Each chord plays for 1 bar + 1/64th extra, causing an overlap of the chord notes on the first 1/64th of each bar (from bar 2 onwards).
  
  

When using the 1/8 or None Quantize setting

• The first chord plays for less than one bar (57/64ths).
  
• The second chord starts 7/64ths early, i.e. it begins during the first bar.
  
  

Hope that helps

[drGrov]

Being stubborn, I thought I'd have one last go with Bitwig and the NDLR and see what happens when the NDLR's pad quantization is set to 1/8th. The 2nd and following recorded pad notes consistently changed 1/8th note earlier than I was expecting - something I can't blame on my setup .

Watching the NDLR's main display I think I've come up with a possible cause. The NDLR seems to change chords early when the chord sequencer is running. I think that change is happening before the the last 1/8th note of the chord (e.g. during the 7th 1/8th note in a single bar chord). The NDLR then quantizes this change to the next 1/8th note and so changes early. This doesn't happen with 1/4 note quantization as the NDLR is already in the last 1/4 note of the chord when it decides to change.

This doesn't account for the odd 1/64th timings and lengths seen on the Deluge but might explain the obviously early changes