Pads not turning on with custom config

I’m having a strange issue. I have a 4x8 group of pads that light up in the startup animation and were working a few days ago, but now only a few respond to midi. I have this script to test them using the sendmidi utility from: https://github.com/gbevin/SendMIDI

#!/bin/bash
for i in {0..31}
do
sendmidi dev "PHENOTYPE MIDI 1" ch 2 on $i 127
done

I configured all these to respond to Channel 2, Notes 0 - 31. Yet only Notes 1, 5, 9, 13, 17, 21, 25 work. Up until a few minutes ago, 29 worked also. And after pushing the default config and reloading my config, note 29 works again! The configurations are identical except for the note number. The pads do work with the default configuration.

Not working pad:

Working pad:

The only difference is the note number. I’ve tried changing the note number and channel of the not working lights but nothing seems to work. Restoring the default configuration, it does work with the default config. It was working fine a few days ago and I haven’t changed anything with this part of the configuration. I’m not sure why they are not responding anymore. In the default configuration, they do light up (though other pads set to the same messages do too as that’s how it’s configured). The script to test the default config is:

#!/bin/bash
for i in {64..95}
do
	sendmidi dev "PHENOTYPE MIDI 1" ch 2 on $i 127
done

Default config:
default.ytx (404.7 KB)

Custom config:
phenotype.ytx (403.8 KB)

I’m thinking this is possibly an issue with the configuration loading or being sent to the controller since that note 29 stopped working and started working after I loaded the default config followed by loading my custom config. Not really sure what is happening or how to get these pads responding to midi again.

Hello @lucian!

I am trying to think of ways to test your configs.

I’d suggest to start from the clean default config and only change these buttons’s notes and see if the sendmidi script works alright.

And then build from there.

I can’t see anything wrong with the config yet, I’ll keep looking.

Maybe Kilowhat is failing, it’s hard to know from here.

If the bug persists, we can arrange to have a call and check this out together :slight_smile:

Cheers and have a nice weekend!

@francoytx

So I started with the default config and it started to work ok. But sometime when setting some other pads to channel 1, the problem came back exactly the same. Other things I’ve noticed is that the controller remembers the last state even after being powered off. Maybe this is intentional? Or maybe it things the pads are in toggle mode? They are all set to momentary.

Also, when sending midi to change certain pads, other pads’ intensities get changed sometimes. The other pads do not have value to intensity or anything like that set nor are they on the same channel as the messages being sent. Perhaps this is a different issue, but I put it here in case it helps to debug this one.

I’ve tried both FF and Chrome on Linux for running Kilowhat but there doesn’t seem to be a difference. I can try setting them again from the default config to see exactly where they stop working, if it can even be determined.

Hello @lucian!

We have a feature called “Remember state” which does exactly this.
Disable it from the general configuration tab (wheel icon at top right corner) in Kilowhat if you’d like this feature off.

This is strange, but seems like a config issue.
Like I said, we’re up for a call if the problem persists to help you debug it.

Hope you can find the issue! Otherwise, let us know.

Cheers!

@francoytx Yeah I noticed the save state a little after I sent this message so that is no problem. I will take you up on that offer. I will try to start from the default config again and see if I can pinpoint when it starts to behave strangely and get back to you.

1 Like