blahlicus/animus-family

keyboard firmware family for arduino compatible atmega u series microcontrollers

Animus

Introduction

This is an Arduino based firmware for use by devices compatible with the Arduino Leonardo firmware (Leonardo, Mico, Pro Micro, etc) and the Arduino SAMD21 firmware (Zero, MKR1000, M0, etc). Animus is highly customisable and modular, allowing for additional modifications to be made without needing to edit the base code. Animus is one of the first of its kind where persistent live editing of the keyboard layout is possible via serial commands sent from the host computer. Resource management is important as the hardware (atmega32u4, etc) has limited flash memory and EEPROM, heavy optimisation has been done in order to preserve resources.

Features

• NKRO (Up to 113 keys)
• Mouse controls (movements, left click, right click, middle click, previous button, next button, scroll wheel)
• live key layout editing (no need to reupload layout)
• persistent key layout (keyboard layout is remembered across computers)
• split keyboard compatible via I2C (works on stuff like ergodox/diverge)
• up to 256 FN layers limited by EEPROM
• up to 256 layers limited by EEPROM
• FN keys, spaceFN, toggleFN
• "dual-keys" functionality (commaShift, etc)
• default combo keys (shift+??/ctrl+??/altgr+??)
• macros
• tap dance keys
• media keys
• serial communication (for editing layout, layers, name, etc)
• device embedded unique id
• modular modding system (plugins could be added to provide additional functionality)
• low ROM usage (currently uses less than 500 bytes)
• multi-HID emulation

This wiki contains information for both non-programmers and developers alike, check out the side bar for more information.

Building

OS X

The contents of the libraries/ directory must be copied over to ~/Documents/Arduino/libraries/, the HID-Project/ in particular. You can create a symlink to always ensure your libraries are synced with the repo:

>>> cd libraries/HID-Project && ln -s `pwd` ~/Documents/Arduino/libraries

If this step wasn't done, this would result on a Comilation Errror due to the missing HID-Project dependencies.

animus-family's Issues

bug: uniquekreqinfo command not working properly

this is due to the use of builder tags builder_kbname and etc

the precompiler directives separates the string KBINFO into several strings then combine them with the following c++ string syntax:
"string1" "string2" is equal to "string1string2"
however, the arduino String object does not share this behaviour

Expire tap dance reading immediately upon match

I love the tap dance feature, but I'm finding it somewhat frustrating in its current implementation. I'm currently testing it out using it as such:

1. Press & hold for Fn
2. Tap twice for FnToggle

It does work, however I notice that I have to wait for the timeout to expire prior to being able to use my shifted layer keys. Ie. I have the W key on layer 1 mapped to the up arrow. If I press Fn+w it should always be "up" but if I press it too quickly then I get a "w" instead.

I'm wondering if it would make sense, when the first key in a tap dance combination is held down, to trigger the final press as soon as the I press a key to go with the modifier.

Thinking about this more, I'm not sure it makes total sense, but I can't think of another way to improve this behavior. I don't want to bring the delay setting too low, as it'd be frustrating to try to tap that quickly every time.

Maybe there's a better way to determine when to stop listening for the second tap dance key than using a delay?

Help with custom keyboard needed

Hello and thanks for your efforts.
I'm trying to use your firmware with my custom keyboard (using Pro Micro)
Here is my wiring

   |2  |3  |4  |5  |6  |7  |
|16|   |   |   |   |   |   |
[15|   |   |   |   |   |   |
[14|   |   |   |   |   |   |
[10|   |   |   |   |   |   |
[9 |   |   |   |   |   |   |

I'm using this settings in Animus Firmware Builder:

Then I flash it with Arduino 1.8.0 - all goes fine

After that I'm opening Arbites and Terminus 2 Device

Applying it(it says done) and assuming that defined keys should work, but it does not - can't get any input using my keyboard, none of keys sending any input actually.

Am I missing something here?

P.s. This is not my first hand-wired keyboard.

animus 3 - host keyboard is significantly slower than slave

The host half of the keyboard is significantly slower than the slave. The reason for this is that Wire.requestFrom blocks. The wire library does not provide a way to not block, but there are alternative libraries.

Async1MSDelay really takes between 5 to 7 milliseconds on the host, which means that we lose large chunks of time. This is almost certainly the reason why I only had debounce issues on the slave half of my keyboard; the host is so slow that it is virtually impossible to experience bouncing.

Implement: Macro Mod

Implement some sort of persistent macro system with EEPROM utilisation.

reserve space for layers may have to be reduced from 1000 to 500 for some space to save the macros.

Teensy 2.0 support

Hello,
Just discovered your firmware and it sounds great, I want to use it with my hand-wired keyboard, but I'm using teensy 2.0 as my keyboard controller.

And when I try to build firmware I'm getting an error:

\AppData\Local\Temp\arduino_build_252420\sketch\AnimusKeyboard.h:25:17: fatal error: HID.h: No such file or directory

As I understand teensy boards are not supported. If you'll have time please add support for it.
Thanks!

Add tap dance module

Enhancement as per this feature

Diverge 3 debouncing issues still occuring with Animus 2.7.0

Just updated to Animus 2.7.0 on my Diverge 3. I saw one of the major updates to this version is that the debouncing issues have gone away. This has not been my experience. On 2.3.1 I had to adjust the builder_refresh to be around 14 to be somewhat stable. On 2.6.0 i found that about 17 for the builder_refresh rate was the most tolerable. On 2.7.0 however, even at 100, the debouncing issues are still strong. The higher I raise it sure, they start to go away but, of course this makes the keyboard much less efficient. I would really like to be running 2.7.0 but, the debouncing issue is really frustrating. Thoughts? Something else I can try? Thanks!

Diverge 3 animus master

When I upload master/HEAD of this repo to my keyboard, most of the keys don't work and the others produce garbage.
If I upload the version in the zip found at https://unikeyboard.io/animus/ that is a bit older (animus-keyboard.h/cpp is still around) it works.
Is this a known problem?

I2CHost to I2CGuest EEPROM writes might be skipped if PC sends data too quickly

@BlackCapCoder I was looking through the source code and noticed that it was possible for the host to drop bytes if the PC is sending data to the host quicker than the guest could ask for it.

Currently, ModI2CGuest pings the host every 50ms (as defined by PULL_RATE), every time that happens, a 28 byte package is sent from the host to the guest. If the PC sends packages at a rate quicker than 50ms, then packages are dropped in between due to this code:

          if (EEPROMPacketSize > 0)
          {
            EEPROMPacket[EEPROMPacketIndex] = (byte)Serial.read();
            EEPROMPacketIndex++;
            EEPROMPacketSize--;
          }
          if (EEPROMPacketSize <= 0) <---------problem starts from this line
          {
            pendingEEPROMUpdate = true;
            Comms.mode = 0;
          }

Whilst EEPROMUpdate is pending for the ping from I2CGuest, any further received packages would be dumped because EEPROMPacketSize is 0 and it would reset to mode 0.

I see two solutions to resolve this and I could implement it if you don't want to work on this, but I could really use your insight on this:

Solution 1: Change Comms.mode 6 so that bytes from the PC isn't removed from the buffer until the package was sent from host to guest, this would involve changing the code snippet above to this:

          if (EEPROMPacketSize <= 0 && pendingEEPROMUpdate == false)
          {
            pendingEEPROMUpdate = true;
            Comms.mode = 0;
          }

We will also have to add a Comms.mode =0; to here in the onReceive function:

  if (pendingEEPROMUpdate)
  {
    SetSubEEPROM();
    EEPROMPacketIndex = 2;
    SerialLoaderByteStatus = 0;
    pendingEEPROMUpdate = false;
    Comms.mode =0; <----------here
  }

Which would prevent Comms.mode from resetting to 0 until the package was completely received by the guest, thus prevent Comms from dumping bytes to mode 0.

This solution is easy to implement but it would restrict the bandwitch of editing EEPROM from host to guest to 560 bytes per second, thus, updating the 5120 EEPROM on the guest would take around ~9 seconds which is quite long.

Solution 2: Temporary disable the master/slave switching and have the master be set to the host for the duration of the transfer.

Comms.mode 6 would need to be changed (or we could make a mode 9) where it would have to define the total number of bytes of all the packages at the start as a short, then split it up into two bytes and send it over to the guest in one go.

Currently a package looks like this and sending 5120 bytes to the guest involves sending several of these packages to the guest:

byte0: start address byte A
byte1: start address byte B
byte2: package size
byte3: data
byte4: data
...

byte0 and byte1 are combined to form a short, byte2 only needs to be a byte because the max size for each package is 28 only.

I could create a Comms.mode 9 that has the following structure instead:

byte0: start address byte A
byte1: start address byte B
byte2: package size byte A
byte3: package size byte B
byte4: data
byte5: data
...

Then only the first package would contain the starting address and package size whilst the trailing packages would only contain data, this would be similar to how Comms.mode 8 works for editing the host's EEPROM.

The idea is to lock the guest from typing or updating other info so that all bytes received by the guest during that time would be correct data to be written to EEPROM.

The above should take less than a second to write the entire EEPROM on the guest side so it should be OK to temporarily disable the master/slave switching.

Do you have any insight on how we might be able to deal with this problem?

Remapping Caps Lock to Ctrl when holding and Escape when tapping.

Hi guys.

I'm looking for a keyboard and as such I'm trying to find the right firmware for a keyboard.

I have a question for keyboard mapping. I'm a vim user so it's probably a bit specific but in particular, here's what I'm hoping to achieve.

When holding caps lock key, it would become control.
When tapping caps lock key, it would become escape.

I'm currently using a software to do it but it would be good to be able to make it in the hardware.
You can find more information here: http://www.economyofeffort.com/2014/08/11/beyond-ctrl-remap-make-that-caps-lock-key-useful/

So is this possible for animus firmware?

animus 3 - comms mode 7

Mode 7 is used to update some variables in EEPROM:

animus-family/animus-3/source/core/Comms.cpp

Lines 132 to 152 in aa22774

	else if (mode == 7) // update basic info
	{
	if (Serial.available()>0)
	{
	PersMem.SetEEPROM(MEM_LAY_COUNT, (byte)Serial.read());
	}
	if (Serial.available()>0)
	{
	PersMem.SetEEPROM(MEM_NKRO_MODE, (byte)Serial.read());
	}
	if (Serial.available()>0)
	{
	PersMem.SetEEPROM(MEM_IS_USBHOST, (byte)Serial.read());
	}
	if (Serial.available()>0)
	{
	PersMem.SetEEPROM(MEM_REFRESH_RATE, (byte)Serial.read());
	}
	PersMem.CommitEEPROM();
	}

Firstly, if some of the 4 calls to Serial.available evaluates to false then we would update the wrong variables, or not update anything at all. Consider something like this:

printf '\0\1\2\3\7' > /dev/ttyACM0 # handshake
printf '\2\1\1\x20' > /dev/ttyACM0 # new data

It makes sense to split the logic that deals with the handshake from the one that deals with writing data, but this separation of logic often carries overhead - be it function call overhead or spinning up an entirely new program as in the case of bash -, which might delay the payload enough to miss align the variables.

Secondly, in ModI2CHost mode 7 means to dump the guests EEPROM:

animus-family/animus-3/source/core/ModI2CHost.cpp

Lines 237 to 251 in aa22774

	else if (Comms.mode == 7) // request read sub EEPROM
	{
	short addr = 0;
	while(addr < MEM_EEPROM_SIZE)
	{
	GetSubEEPROM(addr);
	Wire.requestFrom(8, 32);
	while(Wire.available())
	{
	Serial.println(Wire.read());
	}
	addr = addr + 32;
	}
	Comms.mode = 0;
	}

Shouldn't this instead request that the guest also update its variables?

Feature request - Animus 3 - Ability to change led colors at runtime

LEDs are currently hardcoded to a neat rainbow color:

animus-family/animus-3/source/animus/ModLED.cpp

Lines 37 to 44 in 81f074a

	void CModLED::RefreshLED(void)
	{
	for (short i = 0; i < LEDCount; i++)
	{
	LEDs[i] = CHSV (GetData(2 + i * 2), GetData(2 + i * 2 + 1), Global.LEDBrightness);
	}
	FastLED.show();
	}

It would be nice to be able to change this at runtime, rather than just the brightness. Ideally I would like to change the color in response to a change in active layer.

Animus 3 - double presses

This may or may not the the same issue as #30.

I am getting a lot of double presses on the right half of my diverge 4, but not on the left. I have tested with the refresh rate set all the way up to 80, and the problem is still present, which leaves me doubtful that this is a debounce issue.

For reference, with a standard qwerty layout and the refresh rate set to 17 on the left half and 50 on the right, I typed "lorem" a bunch of times:

lorem lorem llorem lorem loorem llorem lorem lorem loorem lorem loorem lorem lorem
lorem lorem lorem lorem lorem lorem llorem llorem lorem lorem lorem loorem lorem lorem
lorem lorem lorem lorem lorem lorem lorem lorem lorem lorem lorem lorem lorem lorem
lorem lorem lorem lorem loorem lorem lorem lorem lorem lorem lorem lorem lorem lorem
lorem lorem loorem lorem lorem lorem lorem lorem lorem lorem lorem lorem lorem lorem
lorem lorem lorem lorem lorem lorem loorem loorem lorem lorem loorem lorem lorem lorem

l and o are the only letters to be duplicated, both of which are on the right half of the keyboard. It is also curious that I always get double presses, never 3 or more which you would expect with debounce.

Some key mappings do not send any input

Hello,

I noticed that when I try to map some keys to certain functions, nothing happens. I'm using this utility to detect key presses.

List of key mappings with no effect (that I noticed; there may be more):

• M Play
• M Pause
• KBSearch

Interesting about the M Play/M Pause mappings is that all other media mappings work -- they produce the expected output in the KeyCodes utility and I can control my media player and volume with them. I haven't tried other KB* mappings.

Also, i'd expect a 'M Stop' and 'M PlayPause' mapping instead of those two, that seems to be the standard. Can you clarify why it's 'M Play' and 'M Pause' instead?

Thank you!

dual keys stop working - animus 3

It is possible for dual keys (space || shift, enter || ctrl) to lose their second functionality. For instance, backspace || shift might suddenly start acting as a regular backspace. Once one dual key stop working, all the other dual keys also stop working.

I am unable to reproduce the behavior at will, but it eventually happens, usually during heavy typing. A restart fixes the issue. I am using a brand new diverge 4.

Possibly increased key chatter since updating to Animus Innova?

Not sure if this is hardware or software. My Terminus Mini was out of use for a few months before I updated the firmware.

Diverge 3 does not work at all during Mac boot

Tested on:

• Late-2018 Mac Mini (macOS 10.14.5)
• Early-2015 Macbook Pro (macOS 10.13.6)
• Mid-2012 Macbook Pro (macOS 10.14.4)

On all Mac computers that I tried (and on all of their USB ports, with or without USB hubs), my Diverge 3 keyboard does not work at all during the boot process. This means that when booting up the computer you can't hold down the "option" (alt) key to choose which drive to boot from, or hold cmd+R to enter recovery mode, or use any other startup commands. All keyboard input is completely ignored at this stage.

It also means that if you have Filevault (Apple's full disk encryption) enabled, you can't enter your password in any way when turning the computer on (after it being powered off), as typing on the keyboard has no effect on that login screen.

On the other hand, if FileVault is disabled, OR if you are waking up the computer from sleep, you can log in just fine because in those cases the login window is shown to you by MacOS, not by Apple's boot stage software, and in MacOS the Diverge keyboard works just fine.

I have tested an external Apple keyboard, and that works fine during boot. I have read user reports online that some other third party keyboards work too, e.g. the AmazonBasics USB keyboard, as well as reports that some other brands don't work.

I have talked with Apple, but they kept angrily insisting that the problem is with the keyboard, although they of course couldn't tell me what the actual problem was, or why they were so sure of it.

Given that some third party keyboards do work during Mac boot, this could potentially be a hardware or firmware issue with Diverge, thus this ticket.

If anyone else is using Diverge with Macs, please chime in whether you're facing this issue or not. I suspect that this is not an easy bug to hunt down, so it would be good to know that I'm not the only one with this problem.

Toggled layers and their behavior with macros

I have a dedicated layer just for Plover (Layer 4) which I activate with the toggleFn4 special key. I wanted to define a macro in this layer that would press some keys for me, but stay in the steno layer, however, I found out by experimentation that this is not possible.

When I simply created a macro and assigned it to a key on Layer 4, the keyboard would reset to Layer 0 when the macro completed. I tried to add another "key", toggleFn4, at the end of the macro, but that had no effect.

I already learned to live with the fact that regular Fn keys always reset the keyboard to Layer 0 when released, so I need to either not have any of them on the layer or make a mental note in my head about which layer I'm currently on and update that whenever I press layer keys. But I was expecting macros to work.

It would be great if this could be fixed.

Key sticking issue until I upload firmware

I'm on the latest master firmware (commit fd05771) on my Diverge II. I've noticed that any time I reboot my computer or unplug/plug in the keyboard's USB, the master side starts sticking. By that I mean I have to hit every key four or five times before it actually registers. I can work around the issue by uploading the latest firmware again. I actually started noticing this issue when I updated to the commit that contained the debouncing code. Any thoughts on what might be happening here? Any other detail I can provide?

Shift dual keys do not work with each other

I have the following dual keys defined: commaShift, endShift

If I press a dedicated R Shift ("right Shift") key and commaShift, I will get < (Shift-ed comma, the desired outcome).

However, if in the example above I press a dedicated L shift ("left Shift") key instead of R Shift, I will get an unshifted comma, which is surprising and makes it impossible (without other special keys) to get a < character if you don't have a dedicated R Shift key in your layout, very much limiting the usefulness of such a dual key.

Moreover, if in the example above I press endShift instead of L Shift, in addition to getting a , instead of the desired <, the End key will also fire when I release endShift, screwing up cursor position. I guess that might be related to #19. Needless to say, that behaviour is also very inconvenient.

diverge 3 - sticky modifiers not working?

I wanted to try out stickyFN on a diverge 3, but for some reason none of the sticky keys is generating a key press and I don't see what I am doing wrong.

To make this easier to reproduce: I took the default keyboard layout from the unikeyboard website and replace one of the shift keys in that default layout with a StickyShift. My expectation is that the next key pressed after hitting the StickyShift key would be capitalized, but it isn't.

Any hints on how to get this working?

btw) this is on a fully up to date master; I am using this keyboard on a Linux machine (Slackware)

Compilation Error for missing file

I'm trying to update my firmware into 2.5, as well as the current HEAD of the master branch.

Following the guide in https://imgur.com/a/8UapN, it results on a compilation error.

Here's the verbose logs for diverge-3-master:

Arduino: 1.8.5 (Mac OS X), Board: "Arduino Leonardo"

/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/arduino-builder -dump-prefs -logger=machine -hardware /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware -tools /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/tools-builder -tools /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -built-in-libraries /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/libraries -libraries /Users/burnzz/Documents/Arduino/libraries -fqbn=arduino:avr:leonardo -vid-pid=0X2341_0X8036 -ide-version=10805 -build-path /var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970 -warnings=none -build-cache /var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_cache_127356 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.arduinoOTA.path=/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.avr-gcc.path=/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.avrdude.path=/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -verbose /Users/burnzz/dev/animus-family/animus/animus.ino
/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/arduino-builder -compile -logger=machine -hardware /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware -tools /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/tools-builder -tools /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -built-in-libraries /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/libraries -libraries /Users/burnzz/Documents/Arduino/libraries -fqbn=arduino:avr:leonardo -vid-pid=0X2341_0X8036 -ide-version=10805 -build-path /var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970 -warnings=none -build-cache /var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_cache_127356 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.arduinoOTA.path=/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.avr-gcc.path=/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.avrdude.path=/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr -verbose /Users/burnzz/dev/animus-family/animus/animus.ino
Using board 'leonardo' from platform in folder: /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr
Using core 'arduino' from platform in folder: /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr
Detecting libraries used...
"/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E -CC -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR  -DUSB_VID=0x2341 -DUSB_PID=0x8036 '-DUSB_MANUFACTURER="Unknown"' '-DUSB_PRODUCT="Arduino Leonardo"' "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/variants/leonardo" "/var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970/sketch/animus.ino.cpp" -o "/dev/null"
"/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E -CC -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR  -DUSB_VID=0x2341 -DUSB_PID=0x8036 '-DUSB_MANUFACTURER="Unknown"' '-DUSB_PRODUCT="Arduino Leonardo"' "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/variants/leonardo" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/libraries/EEPROM/src" "/var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970/sketch/animus.ino.cpp" -o "/dev/null"
"/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E -CC -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR  -DUSB_VID=0x2341 -DUSB_PID=0x8036 '-DUSB_MANUFACTURER="Unknown"' '-DUSB_PRODUCT="Arduino Leonardo"' "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/variants/leonardo" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/libraries/EEPROM/src" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/libraries/HID/src" "/var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970/sketch/animus.ino.cpp" -o "/dev/null"
"/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E -CC -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR  -DUSB_VID=0x2341 -DUSB_PID=0x8036 '-DUSB_MANUFACTURER="Unknown"' '-DUSB_PRODUCT="Arduino Leonardo"' "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/variants/leonardo" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/libraries/EEPROM/src" "-I/Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/libraries/HID/src" "/var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970/sketch/animus.ino.cpp" -o "/var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970/preproc/ctags_target_for_gcc_minus_e.cpp"
In file included from /Users/burnzz/dev/animus-family/animus/animus.ino:11:0:
/var/folders/_6/97xr9bbs4fz34gkr8dy_b6180000gn/T/arduino_build_517970/sketch/KeyboardInterface.h:24:25: fatal error: HID-Project.h: No such file or directory
 #include "HID-Project.h"
                         ^
compilation terminated.
Using library EEPROM at version 2.0 in folder: /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/libraries/EEPROM 
Using library HID at version 1.0 in folder: /Users/burnzz/Downloads/Animus/Arduino.app/Contents/Java/hardware/arduino/avr/libraries/HID 
exit status 1
Error compiling for board Arduino Leonardo.

I tried copying over the contents of libraries/HID-Project/src/* to the diverge-3-master/* but no luck.

I might be missing a step in here. Can you show me what I might be missing?

Cheers!

Dual-roles win/gui/cmd key

see this.

Function request to add the win/gui/cmd key to the dual roles module.

Question about layers

Do the layers on Animus work like the one on ErgoDox where you only need to specify changed keys (allowing for multiple layers to stack for specific uses)? Or is each layer a distinct key layout that would need to be fully defined

Releasing a dual key after holding it down for a while sends unexpected key

Common scenario I run into all the time: I have a dual key defined like commaShift. Sometimes I press it intending to use it as Shift, but then release it after half a second or so without pressing any other key. Sometimes that's because I changed my mind, or realized that I need Alt instead of Shift. Happens all the time.

Currently in this scenario the dual key will fire a comma (if it's commaShift) when you release it. This is annoying because it's unexpected, and for some key combinations that I use like endShift it takes a lot of keypresses to recover.

I propose that the comma key (in case of commaShift) should only be sent if the delay between pressing and releasing that key was lower than some threshold, e.g. maybe 200ms. If more time has elapsed, send a lone shift keypress instead (which will probably have no effect but seems more correct than the other alternative, sending nothing).