#1

ok…
posting this here since NORNS Help was closed.
(sorry if it’s not the right place)

i posted this under MANGL but it looks like i should post this here in NORNS HELP so i am moving it here.

my reference is with MANGL since i was was broadcasting last night but i will look at other scripts as well tonight.

i’m having the old MIDI control issue again where norns/MANGL will not respond to certain control assignments.

norns will (learn) the controller in the MIDI learn parameters page.
so i know it will see it.
just won’t react to it.

weird thing is…different MANGL tracks do not like certain CC numbers.
(i guess)

for example:
voice TWO volume on MANGL will not respond to CC 26 but it will with CC 27.
voice THREE volume on MANGL will not respond to CC 26, 27 or 32 but it will react to 8.
Delay send for ONE doesn’t like CC 9 but 8 will work.

this makes trying to control MANGL a bit of a rollercoaster.
:stuck_out_tongue:

TWO is controlled by fader 3.
THREE is controlled by knob 20.
Delay send for ONE is to the left of where it should be.
(you get the idea)

i did get a powered USB hub to alleviate USB connectivity on norns but this was happening before and after i added the hub.

tried a fresh start from SLEEP but it seems to be consistent.

thank you for any help!

Mangl
Introducing: Questions
#2

hi spike!

  • what MIDI controller are you using with norns?
  • does this happen when no other hardware is attached as well?
1 Like
#3

hm… one thing is that if a mapping is created, and then the underlying set of parameters is changed (e.g. by an update), then the mappings will be off. (because under the hood, the target of a control mapping is a numerical index and is not aware of the actual name or “identity” of the parameter.)

so you might want to try clearing mapping files (.pmap) from the script’s location in ~/dust/data

but of course that doesn’t specifically address some problem where certain CC numbers are usable and others are not. that makes no sense at all to me (the CC number is just a byte value, nothing in the midi handling pipeline should be particular about it)

1 Like
#4

i will test some more tonight.
was getting ready to live stream my noiz when i ran into this.

FaderFox MX12
(and the usual ARC and GRID)

i will also test it with a FaderFox PC12 and UC44, 16n, and well…might as well give the BeatStepPro a spin.
:stuck_out_tongue:

i’ll give that a try when i get back to the studio later tonight and report back.

#5

oooh…me touch code?
heh!
now…i’m GREAT at breaking things but…touching code and or files of code is really a dangerous idea.
:slight_smile: :rofl:

i’ll run a backup of norns and then attempt that if the previous tests don’t produce any good results!

#6

you can do it all in Cyberduck! :slight_smile:

image
image1668×1262 315 KB

once you’re in, go to dust > data > mangl and delete any .pmap files

2 Likes
#9

note: all testing was done with nothing else connected other than the MIDI controller and then the WiFi thingie was added for the .pmap scenario.

Booted up and saw FaderFox MX12

  • same weird behavior.

FaderFox PC12

  • 1, 2, 3, work
  • 20 works
  • 26, 32, 33, 34 do not

Switched to BeatStep Pro

  • 19 works, 20 and 26 don’t

16n

  • learned but did not react to 32, 33, 34
  • tried assigning 45, 46, 47 and they work.

————————
DELETED .pmap
————————
[!made an entire norns backup first!]

FaderFox PC12

  • 32, 33, 34 all now work!

FaderFox MX12

  • 26, 27 now work

FaderFox UC44

  • randomly assigned knobs and faders and they work.

16n
32, 33, 34 all work

BeatStep Pro
19, 20 and 26 all work

Even went through and randomly assigned knobs and faders on different controller and they ALL seem to work!

THANK YOU SO VERY MUCH!

now…questions…
Is there a way to keep that .pmap business clean?

Or will I just need to delete it from time to time?

2 Likes
#10

You need to delete and recreate the mapping whenever the script changes the number or order of its parameters

This should be prominently documented somewhere, apologies

3 Likes
#11

the new param system (which is done, in testing now) handles pmaps correctly and this will not be a future problem.

6 Likes