16n sliders exhibit significant jitter with the sines script

[aidanreilly]

16n running firmware 2.1.1

I am experiencing signficant jitter in sines when using a 16n that otherwise does not exhibit jitter in other applications, 16n editor shows no jitter. The active slider jumps around making the 16n unusable.

@p3r7 any ideas? can you replicate?

[aidanreilly]

trim.AAC48AB9-89AD-4E55-8B8B-A71721B8B74C.MOV

[aidanreilly]

I need to debug a bit more and see if I can replicate in other Norns scripts.

[aidanreilly]

It's weird that I don't see jitter in renoise or the 16n editor though.

[aidanreilly]

Something changed in a recent 16n firmware maybe?

[p3r7]

mhm, is 2.1.1 a recent release?
an eventual change on a recent norns release could also be to blame.

idk on which version my 16n currently is. i'm away from my 16n rn so can't really test & compare.

[aidanreilly]

2.1.1 is the latest. I'll dig around and see what's up.

[p3r7]

another potential culprit could be the "virtual fader" proxy params logic introduced by 0c91a5d.

it worked fairly well but maybe did norns introduce a degradation of performance for this "param setting a param" paradigm, idk.

[aidanreilly]

Indeed it does seem to be related to 0c91a5d. I removed this in a dev branch and it seems to have fixed the problem.

[p3r7]

rad that it worked, but weird that norns got a degradation in performance around params. i will relay the info, that might be worth investigating.

[aidanreilly]

I would like to see this replicated on another system before reporting it as an issue. I think any 16n on latest f/w should see this. I'll ask in the sines thread.

[aidanreilly]

https://llllllll.co/t/sines/39292/388?u=oootini

[m-r-m-s]

sines-test.mov

I was experiencing some issues with my 16n on v2.1.1 as described here. Specifically, I wasn't getting the full 0-127 travel and whenever I started sines on the norns, i.e. the default value always started at 2 instead of 0 and I could never get it to 0 using the 16n faders.
I re-flashed the Teensy LC on the 16n with the 2.1.1 fw & that resolved the issue. This video is after the re-flash. Thanks again for all the work ya'll are doing on sines! I hope these data points are helpful.

[aidanreilly]

sines-test.mov

I was experiencing some issues with my 16n on v2.1.1 as described here. Specifically, I wasn't getting the full 0-127 travel and whenever I started sines on the norns, i.e. the default value always started at 2 instead of 0 and I could never get it to 0 using the 16n faders.

I re-flashed the Teensy LC on the 16n with the 2.1.1 fw & that resolved the issue. This video is after the re-flash. Thanks again for all the work ya'll are doing on sines! I hope these data points are helpful.

Thanks! So if you're on latest 16n firmware and not seeing the glitchy faders my 16n unit must be faulty? Odd.

[m-r-m-s]

Hmmmn, up thread you mentioned that the 16n seemed to work with other applications tho correct? Also, I later figured out that the full travel issue I was having wasn't related to having to reflash 2.1.1 firmware but because I had the 16n device settings to have it rotated 180 degrees. That might be an issue w/ 16n firmware?

The only thing I noticed in sines was Norns button/ fader combos (Param adjustments e.g. fm index) with Sines being a bit jumpy/ sensitive but it could be more of me as the operator unless someone else can reproduce?

[aidanreilly]

I think this is part of the problem. It's not user error.

The only thing I noticed in sines was Norns button/ fader combos (Param adjustments e.g. fm index) with Sines being a bit jumpy/ sensitive

[aidanreilly]

Hmm. might need to decouple that 16n integration or revise it significantly. The current implementation picks up the active fader value when you hold the button which causes the noisy jump when for example you want to edit the fm index. not ideal for performances for example.

I'd be inclined to disable the 16n params jump feature by default for the new release.

[m-r-m-s]

not ideal for performances for example.

I'd be inclined to disable the 16n params jump feature by default for the new release.

Agree on both here 🙌

[aidanreilly]

Running https://github.com/p3r7/16n_test I see this output:

norns.script.load("code/16n_test/16n_test.lua")
# script clear
calling: clean up tuning mod callbacks
# script load: /home/we/dust/code/16n_test/16n_test.lua
including /home/we/dust/code/16n_test/lib/_16n.lua
including /home/we/dust/code/16n_test/lib/inspect.lua
calling: add tuning mod parameters
# script run
>> reading PMAP /home/we/dust/data/16n_test/16n_test.pmap
m.read: /home/we/dust/data/16n_test/16n_test.pmap not read, using defaults.
<ok>
Engine.register_commands; count: 0
___ engine commands ___
___ polls ___
amp_in_l
amp_in_r
amp_out_l
amp_out_r
cpu_avg
cpu_peak
pitch_in_l
pitch_in_r
# script init
detected 16n, will lookup its confif via sysex
add tuning mod params
pset >> read: /home/we/dust/data/16n_test/16n_test-01.pset
pset :: /home/we/dust/data/16n_test/16n_test-01.pset not read.
done retrieving 16n config
{
  init_values = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
  led_data_blink = false,
  led_power_on = false,
  max_v = 127,
  min_v = 0,
  raw_max_v = 16199,
  raw_min_v = 15,
  rot = false,
  trs_cc = { 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47 },
  trs_ch = {},
  usb_cc = { 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47 },
  usb_ch = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }
}

slider #16 just got its value changed to 109
slider #3 just got its value changed to 103
slider #16 just got its value changed to 110
slider #3 just got its value changed to 102
slider #16 just got its value changed to 109
slider #16 just got its value changed to 110
slider #16 just got its value changed to 109
slider #16 just got its value changed to 110
slider #16 just got its value changed to 109
slider #10 just got its value changed to 124
slider #10 just got its value changed to 123
slider #3 just got its value changed to 103
slider #3 just got its value changed to 102
slider #3 just got its value changed to 103
slider #3 just got its value changed to 102
slider #10 just got its value changed to 124
slider #10 just got its value changed to 123
....
>>

[aidanreilly]

in https://16n-faderbank.github.io/editor/, I see:

Fader Minimum raw value
15
Fader Maximum raw value
8135

The max value does not correspond to what we see in the test script for raw_max.

raw_max_v = 16199,
raw_min_v = 15,

[m-r-m-s]

Interesting...it's a little more than double the value on the 16n editor.

[aidanreilly]

Changed Norns power supply, the 16n is working perfectly now.

[aidanreilly]

I will revisit the param jumps issue separately.