RFP: PatternPlayback Message

[qdot]

Name of Outgoing Message, if any:

• PatternPlaybackCmd

Message Fields:

• PatternPlaybackCmd

  • DeviceIndex: number, Index of device to send command to
  • PatternIndex: number, Index of pattern to send

• DeviceAdded/DeviceList

  • FeatureCount: number: Number of actuators that can playback patterns
  • ActuatorType: List of strings: Describes the actuator type for the pattern, in order of feature count. Vibrate, Rotate, Linear, Estim, etc...
  • Patterns: List of lists of strings: Names of patterns on device, as related to their actuators
  • StepCount: List of uints: Pattern step levels for each actuator on the device.

Describe message usage scenario

Provides a way for users to run patterns built into their hardware. Depending on hardware protocols and capabilities, should also be able to read pattern names/indexes off of toys that allow storage/uploading.

Additional context

Example message:

[
  {
    "DeviceAdded": {
      "Id": 0,
      "DeviceName": "Lovense Hush v48",
      "DeviceIndex": 0,
      "DeviceMessages": {
        "SingleMotorVibrateCmd": {},
        "VibrateCmd": { "FeatureCount": 2 },
        "PatternPlaybackCmd": { "FeatureCount": 2, "ActuatorType": ["Vibrate", "Vibrate"], "StepCount": [1, 1],  "Patterns": [["Wave", "Pulse", "Sawtooth"], ["Wave", "Pulse", "Sawtooth"]]},
        "StopDeviceCmd": {}
      }
    }
  }
]

[{
    "PatternPlaybackCmd": {
        "Id": 0,
        "DeviceIndex": 0,
        "Patterns": [{
            "Index": 0,
            "Pattern": "Wave",
            "Strength": 1
        }]
    }
}]

[qdot]

@blackspherefollower Should this have a strength argument? Do we support toys that allow pattern scaling? Like, estim stuff kinda does, and that might actually get weird since you can individually control channels running patterns, so we might need a feature count on this too?

[blackspherefollower]

I'm pretty sure We-Vibe has pattern scaling. Many also don't. I'm fairy sure I've got devices that have per vibe patterns too.

So maybe it needs a feature count and a step count (steps == 1 if no scaling? Or 0 if using 0 intensity is off?)

Other fun thing, what about devices with custom patterns: the names may or may not be retrievable from the device (thinking new Lovense and MystryVibe). There may even be arbitrary numbers of patterns.

[qdot]

Per vibe patterns? As in you can set different patterns to different vibrators? I mean I guess that makes sense with rabbits and all but damn.

Steps = 1 will be fine if it's binary. Feature count is going to get interesting. We may have to add yet another attribute that denotes whether a device can take patterns per-feature or as a whole.

For custom patterns, I think we can deal with that in UI if we want. The user can play a pattern, name it, then we'll store that in one of our ever increasing number of configurations, and relay that along. If they haven't, we'll just send ["Pattern 1", "Pattern 2"...].

Where are you thinking arbitrary patterns would happen?

BTW, quick update to message format: Instead of doing a string/int dict, I'm just gonna send over a list of strings and enforce pattern name uniqueness in the protocol. Otherwise we could just have 10 patterns named "Pattern", which would suck on the UI side.

[blackspherefollower]

Format change makes sense.

I figured that if the device's pattern controlled all vibes, it'd just have a feature count of 1. Step count would show if intensity control is possible.

Oh. If feature count > 1, does steps control all or individual. FeatureStepsCount?

[qdot]

StepCount is an array that matches FeatureCount's length, so we'd take care of that there.

[qdot]

Updating name to PatternPlaybackCmd, 'cause I'm realizing "[Noun]Cmd" is gonna get real confusing.

[qdot]

"[Verb]Cmd" seems fine tho.

[qdot]

@blackspherefollower Ok. Updated to allow patterns PER ACTUATOR because what if we have a device that, say, rotates and vibrates and we want to mix those and there's different step counts for them.

This whole protocol was a mistake.

[qdot]

I feel like this is now dropping actuators contexts but I'm not sure how to fix that.

[qdot]

I suppose we could have a "ActuatorType" message attribute that matches to the actuator indexes, that follows our generic message verbs.

Have I mentioned this whole protocol was a mistake.

[qdot]

Updated with ActuatorType. This message is going to be dense as hell, but hopefully understandable to developers. I hope.

[qdot]

... v7 maybe?