#2001 keyboard sequencer

KOSMO MODULES
103

I scrolled a bit through the code and found nothing that would indicate that there’s a problem (of course, it works for everyone else i guess, but still).

Is it possible that there’s a grounding problem somewhere? I have to ground myself, otherwise it doesn’t work, and pads 6-8 don’t work as they probably should like i described, it’s weird. Any suggestions?

104

see my post 6 Jan… Don’t think I found a solution.

105

Are the plans to get this back in stock in the LMNC shop?!

106

I missed them going on sale!!

Are there plans to restock again?

Pleeeeeeeaaseeeee!!!

1 Like
107

@lookmumnocomputer - I missed the boat … is there another restock coming?!

1 Like
108

they are back! long time since i saw this sorry haha

4 Likes
109

I’ve implemented an arpegiator feature at Sam’s request, if anyone wants to try it out. It requires a trace cut listed on the module’s project page. Alternate code: GitHub - criggs/lmnc-2001-keyboard-sequencer

10 Likes
110

If anyone does this I’d love to see video

1 Like
111

Here’s a small clip from when I was testing it out:

8 Likes
112

Just did the modification with Chris’s new arp code. Working good for me, nice feature to have.

3 Likes
113

I am having this exact same issue on mine. Has anyone found a reliable solution?

114

This appears to be fixed in the new arduino code which is quicker and more stable.

2 Likes
115

I’m glad the code is working for you :smiley:

Did you need to adjust any of the threshold parameters or have the defaults been stable for you?

116

I didn’t make any other changes and I also previously had the issue of the touchpads triggering 2 steps at the same time. All fixed now.

2 Likes
117

Seems vastly better for me now as well.

Is the arpeggiator code different? Does that code include these updates too?

1 Like
118

I based the arp code off of the 2.2 version Sam updated for the eurorack version, which has pulldowns on the analog I puts (what the bodge/trace cut is needed for) which seems to be more stable when reading inputs.

In the original code, the pad values were ready from left to right and it was looking for a value to drop below a threshold, untouched pads have a value of around 1000.

In the updated code from Sam, it looks like he did a few things to improve the stability:

  • The threshold is inverted, so the sensed values need to be above the threshold. Pads that aren’t touched should be around 0.
  • Pads are ready from right to left (ensues the highest pad wins when multiple are sensed)
  • Some basic smoothing is used as the values are a bit unstable when being read. If a finger is sensed, it will stay active for a few cycles after it stops being sensed to give the finger a chance to be ready again in case a low value is read while a finger is actually being pressed down. If the finger is sensed again, it resets the counter. This does a pretty good job of smoothing in a ‘rightmost finger wins’ strategy.

This code is pretty stable and works well as is, but wasn’t able to be easily adapted to handle arping for a few reasons. When touching on pad, the pads next to it will have values above the sensing threshold. The values of the pads change a bit depending on how many fingers are pressed down. Sometimes, the first pad would get sensed with a small signal over the threshold when pressing the last pad. I did a few things to address this:

  • The threshold is now dynamic, set as a fraction of the highest sensed pad value
  • Pads need to be over the threshold for a configured number of cycles before it’s considered pressed
  • I set a value ceiling of 600, because the top 2-3 pads usually read a higher value than the lower 5. This would make the threshold not work well as a combination of the 2 sets of analog input behavior.
  • I added a rolling sample window for each pad and take the highest read value from that window for improved value smoothing
  • I also kept Sam’s previous threshold countdown style of smoothing and applied it to each pad individually

All that said, the code now has a stable way to know the state of every pad and arping is just cycling through those :slight_smile:

I’m thinking of adding some other configurations to change the sequence mode (swap forwards/reverse, random selection, arp between both rows). If anyone has any other suggestions or requests let me know. I think the Arduino has some on chip storage so I’ll probably use that to store any user input configuration so it survives power cycles.

The arp code in its current state is here:GitHub - criggs/lmnc-2001-keyboard-sequencer

4 Likes
121

Nice work !

As an alternative to using multiple Serial.print statements to print a combination of text and variables, you may want to have a look at LibPrintf.h You can find some examples of its usage in the code snippets thread.

1 Like
122

Looks like you got it sorted :slight_smile:

123

Good call! I’m not super familiar with the various arduino libraries to make the code a bit more developer friendly, and the lack of a normal printf for serial has always been annoying. Thanks!

1 Like
124

There is a define PRINTF_DISABLE_ALL you can set that will disable all printf statements. So if they are only meant for debug purposes and you want to get rid of them without having to edit the file, just set that define and recompile.

1 Like