[Feature] Allow for multiple configurations & variations in a sound pack

[ctsstc]

A sound pack contains the sounds, but it would be nice to allow for different configurations within a sound pack. This way the sounds can be re-used without creating a redundant sound pack. For example maybe I want to have a basic duck sounding pack, but then I also want a configuration with additional geese sounds when pressing backspace, space, etc.

I could also see this being beneficial for more complex sound packs where there are many different sounds.

This also brings to mind having key variations like if it could cycle through a set of sounds per key, or randomly choose from a collection of sounds for a key. Then you could potentially have more realistic sounds -- having random sounds per key vs the same sound.

[NotLazy]

Random/multiple sounds per key is planned but I'm not sure I understand the rest of your idea. Could you provide an example of how the config would look, and what pressing certain keys would do?

Eg. "Pressing F plays A.mp3 or B.mp3"

[ctsstc]

Configurations

Could be something like, I download a suck sound pack with:

• Configuration 1 - "Basic"
• Configuration 2 - "Goosey"

Potential structure would be like:

{
  "name": "Beautiful Duck Sounds",
  "configurations": [
    {
      "name": "Basic",
      "defines": {
          ...
        }
    },
    {
      "name": "Goosey",
      "defines": {
          ...
        }
    }
  ]
}

So maybe in "Basic" configuration backspace quacks, but in "Goosey" configuration all keys quack except the backspace, spacebar, and enter make a goose noise. This way the sound pack could still utilize the provided sounds but provide different configurations.

---

Variations

In this example I have a mode defined which could be like cycle, random, reset cycle on non-concurrent presses -- if you press the same key multiple times it cycles, otherwise it resets.

{
  "name": "Beautiful Duck Sounds",
  "configurations": [
    {
      "name": "Basic",
      "defines": {
          "1": {
            "mode": "cycle", // Could also be like "random", "reset cycle on non-concurrent presses", etc
            "options": ["duck.mp3", "duck.mp3", "goose.mp3"]
          },
          ...
        }
    },
    {
      "name": "Goosey",
      "defines": {
          ...
        }
    }
  ]
}

[NotLazy]

I love this idea. I'm going to put it on the roadmap.

Please think of a better, one-word "mode" for "reset cycle on non-concurrent presses" though and I'll implement all mentioned modes. Feel free to mention additional modes as well.

[ghoomfrog]

Please think of a better, one-word "mode" for "reset cycle on non-concurrent presses" though and I'll implement all mentioned modes. Feel free to mention additional modes as well.

@NotLazy elastic_cycle?

[ctsstc]

Maybe just:

• random
• cycle
• cycle-reset

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity in the last 60 days. It will be closed in 7 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant.

[github-actions[bot]]

This issue has been automatically closed due to inactivity.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity in the last 60 days. It will be closed in 7 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant.

[ctsstc]

Is this expected in config v3? Will that land when v3 of the app is published?