touchdesigner: run message objects once per cook + fire impulses only on pulse#136
Closed
jcelerier wants to merge 1 commit into
Closed
touchdesigner: run message objects once per cook + fire impulses only on pulse#136jcelerier wants to merge 1 commit into
jcelerier wants to merge 1 commit into
Conversation
… on pulse
Two related CHOP_MESSAGE binding bugs, found via the golden differential
(feature/td-golden-differential) on avnd_test_impulse (Count read 3, golden 0):
1. The object ran multiple times per cook. message_processor::getGeneralInfo --
a metadata callback TD invokes several times per cook -- called invoke_effect
(i.e. ran the object's operator()). Confirmed via the op's own total_cooks
info channel: total_cooks=1 (one execute) but operator() ran 3x. This
mis-advances every STATEFUL object (counters, oscillators, RNG); stateless
ones were merely idempotent so it went unnoticed. Moved the input-read + run
into run_effect(), called exactly once from execute(); getGeneralInfo is now
metadata-only (audio_processor was already correct -- it runs in execute()).
2. Impulses fired on every cook. The generic per-cook update() fallback called
pulse(field, name), which for an optional-valued port (impulse_button) does
field.value = {std::in_place} -- engaging it. So a bang fired on every frame
instead of only when clicked. Impulses must engage solely via the onPulse
callback (already wired: message_processor -> parameter_update::pulse); the
per-cook update must not. Emptied the generic update fallback.
Result: avnd_test_impulse Count 3 -> 0 (matches the raw-C++ oracle); differential
match 50 -> 51. Beyond the test, this fixes stateful objects advancing N x per
cook and bang/impulse buttons triggering continuously in real TD use.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011s7huWR2wFsLFiMJPjx1z2
Member
Author
|
Superseded by #137, which combines all outstanding work into a single PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two related CHOP_MESSAGE binding bugs, found by the golden differential (#134) on
avnd_test_impulse(a bang → counter: TD readCount=3, the raw-C++ oracleCount=0).Bug 1 — the object ran multiple times per cook
message_processor::getGeneralInfo— a metadata callback TD invokes several times per cook — calledinvoke_effect, i.e. ran the object'soperator(). Proven by the op's owntotal_cooksinfo channel:total_cooks = 1(oneexecute) yetoperator()ran 3×. This mis-advances every stateful object (counters, oscillators, RNG); stateless ones were merely idempotent, so it hid. Moved the input-read + run intorun_effect(), called once fromexecute();getGeneralInfois now metadata-only. (audio_processorwas already correct — it runs inexecute().)Bug 2 — impulses fired on every cook
The generic per-cook
update()fallback calledpulse(field, name), andpulse()for an optional-valued port (impulse_button) doesfield.value = {std::in_place}— engaging it every cook. So a bang fired on every frame instead of only when clicked. Impulses must engage solely via theonPulsecallback (already wired atmessage_processor → parameter_update::pulse); the per-cookupdatemust not. Emptied the genericupdatefallback.Result
avnd_test_impulseCount3 → 0 (matches the oracle); differential match 50 → 51. Beyond the test: stateful message objects no longer advance N× per cook, and bang/impulse buttons no longer trigger continuously in normal TD use.🤖 Generated with Claude Code