Internal media source: silence at idle, drive for patterns + T-code

[quixotic1111]

Problem

Selecting the Internal media source and pressing Start emits a steady
carrier tone even when nothing is driving the output, because
Internal.state() unconditionally returns CONNECTED_AND_PLAYING. The
mute guard in the audio-gen algorithm therefore never engages for the
Internal source.

Conversely, anyone who fixes that idle tone by gating Internal on
activity then finds the built-in pattern generator no longer drives the
electrodes — it doesn't mark itself as activity, so Internal reports
"not playing" and the carrier is muted. That makes Internal + a pattern
(e.g. for electrode calibration) produce no output.

Change

Gate Internal.state() on recent activity, and have every drive source
mark activity:

• External T-code — websocket / TCP-UDP / serial / buttplug, via the
  existing new_tcode_command signal.
• Built-in pattern generator — motion_3 / motion_4, via their
  existing position_updated signal, but only when the emitted position
  actually changes. A static / at-rest pattern marks no activity, so
  the carrier still goes quiet at true idle (the anti-drone behavior).

No change to pattern output, timing, or shapes — patterns emit exactly as
before; this only governs the Internal source's reported play state.

Result

• Internal is silent at true idle (no surprise carrier tone).
• A moving built-in pattern drives the electrodes with no external T-code
  stream — useful for calibration.
• External T-code drives as it always has.

Two files, +59/-1.

[diglet48]

Sorry for the delay.

I don't want to change this, I feel the current behavior already is not great because the lack of feedback in the user interface and harsh ramp. With this change, testing a non-moving position with the mouse doesn't seem possible anymore.

There already is a feature that reduces the output volume when there are no axis changes ("lower volume during pauses"), it is in the volume tab and updates the volume bar.

[quixotic1111]

Hi Diglet48, Thanks for taking a look. I've found an alternative solution, so the specific fix I previously suggested is no longer necessary. Inspired by edger’s Funscript processor, I've developed a new approach for real-time interpretation of frequency axes and script channel swapping. This new method also effectively addresses the volume jumping issue in Restim. I'm developing an application to facilitate this, and I hope to share it with you soon. On Thursday, July 9, 2026, 5:44 AM, diglet48 ***@***.***> wrote: All Good… thank you for taking a look. I can’t recall exactly why I was suggesting this particular fix, but found a different way to achieve the same. edger’s Funscript processor gave me an idea about how to interpret the frequency axes, with almost real time swap of generated “script lanes/channels”. The fix I believe, was a way to avoid the volume jumping to. Sent from Yahoo Mail for iPhone On Thursday, July 9, 2026, 5:44 AM, diglet48 ***@***.***> wrote: diglet48 left a comment (diglet48/restim#42) Sorry for the delay. I don't want to change this, I feel the current behavior already is not great because the lack of feedback in the user interface and harsh ramp. With this change, testing a non-moving position with the mouse doesn't seem possible anymore. There already is a feature that reduces the output volume when there are no axis changes ("lower volume during pauses"), it is in the axis tab and updates the volume bar. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>