RFP: Waveform Message

[riggs]

Name of Outgoing Message, if any: WaveformCmd

Message Fields:

• WaveformCmd
  • ActuatorIndex: Which bit of the device is being actuated (e.g. which estim channel)
  • Waveform
  • Steps: Ordered list of percentile values indicating how the device should actuate
  • Repeat: Boolean of whether the waveform is intended to loop
  • Period: Time (in ms) between steps
  • Delay: Time (in ms) until this waveform is intended to begin
  • Transition: Time (in ms) of the 'cross-fade' between this waveform and the device's current actuation (if any)

Describe message usage scenario This enables precise, arbitrary (enough) motions that aren't subject to connection latency, assuming the client app is sophisticated enough to read ahead, and the device protocol is sufficiently capable.

Additional context I know of several devices in development that will use a similarly 'waveform-based' data protocol.

[qdot]

Ok, so, on the message formation side:

• This doesn't really say what the waveform is for. Is this a vibration pattern? And estim pattern?
• If this is for estim, which the description says it is, isn't ms resolution not nearly enough? Shouldn't this define a function for modulation that samples can be created out of? Similar for HD Rumble.
• Actuator Index per message isn't usually how we do things. We usually address all actuators in our generic messages at once.

I think there's already pieces of this message that were being planned, see buttplugio/buttplug-rs#329 and buttplugio/buttplug-rs#331, which can wrap messages with context in a way that would allow delays. The version of the spec after this is going to focus on turning the protocol into its own pattern serialization format, which will basically handle everything in this message.

The problem with that in relation to what this message is trying to accomplish is going to be that doing everything in Buttplug protocol parlance will be EXTREMELY fucking verbose, so if you did want millisecond level changes, it'd be one message per millisecond, and there may be problems with parsing timing at that point. That's something I'm still working on figuring out, possibly by changing our serialization method to something like PBufs (which it always should've been :( ).

For things that are going to need higher resolution, I'd be more interested in coming up with some way of doing generation through curve fitting via coefficients or something then just putting a bunch of values in, though there's lots of questions about continuity and what not that would bring up.

[riggs]

The waveform describes the variability of the stimulation the user experiences. It can describe the speed of a vibration, the position of a dildo, the power output of an estim signal, etc. It's decidedly not describing a direct control signal of an actuator.

The biggest feature this provides is more granular control over the shape of the sensation curve without requiring extremely low latency. However, as I alluded to, unless the device also has some capacity to ingest some form of queued change message, the actual advantages of this method won't be realized.

If you'll excuse my pedanticism, in order to send multiple waveforms to a device with multiple actuators, some sort of indexing is required, be it explicit or implicit in an ordered list. In order to change just one waveform on a device with multiple actuators, an ordered list requires nullable entries. In order to serialize an ordered list with nullable entries, either explicit indexing or using placeholders is required.

[riggs]

I just read buttplugio/buttplug#100 and this is basically a generalized version.

[qdot]

Oof, ok, this is what I get for replying at the end of a work week.

Actuator Index per message isn't usually how we do things. We usually address all actuators in our generic messages at once.

What I meant is we usually ALLOW addressing all actuators in our generic messages as once. Like, we have lists of substructures that can address individual features.

Anyways, in general, what Buttplug does right now is send instantaneous messages. The plan was to chain these via DelayedDeviceMessage and other modifiers into patterns, but, as I said earlier, that's gonna be wildly verbose in JSON. Less so in something like PBufs. Actually embedding the whole pattern into a single message as a modifier is an interesting idea though, gonna have to think about this and how it'd be used.

For instance, PatternCmd right now is made to access pre-loaded patterns on the toy, but one of the ideas I had for the next version was to be able to create a pattern, name it, and store it on the server at least for the session. Either of our solutions could possibly work for that.

Anyways, I think we're at least headed in the same direction, just via different ways of communicating that direction.

[qdot]

And buttplugio/buttplug#100 follows my above rule of "make an instantaneous command then chain it later via meta-messages". Though honestly ShockCmd or EstimCmd or whatever we're calling it is mostly aimed at TENS and shock collars. I think estim box signal generation is gonna be a far different deal?

[qdot]

Ok, wild idea:

Assuming the possibility of using something less gigantic than JSON, like UBJSON or PBufs, why not just send actual binary audio buffers?