Conversation
- Metrics: 別マシンBridgeでは全フィールド正常取得可能に修正 - Mixer: audioLevel=0の制限を追記 - CUE: 上限15個、Memory Cue色非転送等の制限を追記 - Layer State: 未定義値(17, 2)の遷移パターンを追記 - 未実装パケット: Control/Text/Keyboard のBridge解析結果を追記 - トラブルシューティング: Metrics=0の記載を同一マシン限定に修正
|
Summary by CodeRabbit
WalkthroughPRO DJ LINK Bridgeのドキュメントを更新し、Metrics記述を同一マシン／別マシンでの取得差へ修正、Mixer・CUE章を追加、未実装パケットの一覧を追記、トラブルシューティング文言を改訂。 Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the PRO-DJ-LINK Bridge documentation with technical details regarding Metrics, Mixer, CUE limitations, and unimplemented packets based on real-world testing and binary analysis. The review feedback identifies opportunities to improve the document structure for better clarity and suggests providing more specific technical details on the behavior of CUE data transfers when limits are exceeded.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/wiki/PRO-DJ-LINK-Bridge.md`:
- Around line 30-32: Adjust the wording so the certainty about test results is
consistent between the two sentences: update the sentence referencing 別マシン to
match the tone used for 同一マシン (or vice versa). For example, change
"別マシンのBridgeでは全フィールドが正常に取得可能であることを実機で確認済み (BPM, trackLength, currentPosition,
speed, beatNumber, pitchBend, trackID)。" and
"同一マシン上のBridgeではこれらのフィールドが0で返されることがある。" to either both deterministic ("...確認済み"
and "...0で返されることを確認済み") or both conditional ("...確認されている" and
"...環境により0で返されることを確認"), ensuring the list of fields (BPM, trackLength,
currentPosition, speed, beatNumber, pitchBend, trackID) remains attached to the
appropriate sentence.
- Line 68: 該当ドキュメントの「以下のフィールドが0で返される
(未再検証)。」という未再検証注記の扱いを決めてください：実機で該当フィールドの返値を確認できるなら、テスト手順と結果（実機モデル/日時）を追記して「未再検証」を削除または「検証済み」に更新し、返値が0でない場合は正しい値に修正する；実機確認が不可能な場合は該当行（「以下のフィールドが0で返される
(未再検証)。」）を削除するか、より明確な警告（例：未確認のまま削除予定、検証募集中）に置き換えて読者を誤導しないようにしてください。
- Line 45: 該当箇所の「byte 44-45 (RESERVED領域) に `0x001e` (=30)
が入ることもある。SMPTEモード値の可能性あり。」という記述は推測なので、根拠を明示するか推測表現に改めてください。具体的には該当文を見つけて（上記文言を参照）、Time
パケットと SMPTE 30fps
の関連や参照した仕様書／ログのスクリーンショット／機器挙動の解析結果などの出典を追記するか、出典が無ければ「用途不明」または「推測:
SMPTEモード値の可能性があるが未確認」と明確に修正してください。
- Around line 74-82: The statement claiming "Bridgeバイナリ解析により…確認した" is unclear
and conflates Bridge and node-tcnet; update the table and surrounding text to
explicitly state the provenance for each claim: if the finding comes from the
node-tcnet source (e.g., src/network.ts and its handling of Type 101/128/132 or
the nodeOptions SUPPORTS_TCNCM flag), mark it as "node-tcnet implementation: not
implemented / static flag only" and if you actually analyzed the Bridge binary,
add the binary-analysis evidence (describe the binary offsets/functions or
reference the Bridge disassembly) and mark those entries as "Bridge binary
analysis: not implemented"; alternatively remove any Bridge-specific claim
unless you can supply Bridge binary evidence.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 66b90e67-8e5f-4a12-a9be-1e0fd2f326d3
📒 Files selected for processing (1)
docs/wiki/PRO-DJ-LINK-Bridge.md
📜 Review details
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 64
File: src/tcnet.ts:961-966
Timestamp: 2026-04-09T17:09:02.148Z
Learning: In `src/tcnet.ts` (node-tcnet, TypeScript), the TOCTOU race condition in `performBridgeOsDetection` (where an in-flight ping could overwrite `bridgeIsWindows` with a stale result after a Bridge switch) is resolved by capturing `bridgeIp = this.server?.address` at detection start and checking `this.server?.address === bridgeIp` immediately before writing to `this.bridgeIsWindows`. The maintainer (9c5s) deliberately rejected clearing `bridgeOsDetectionPromise` in `resetAuthSession` (doesn't stop internal execution) and a generation-counter approach (triggers on same-Bridge resets too) in favor of this simpler address-comparison guard.
🔇 Additional comments (3)
docs/wiki/PRO-DJ-LINK-Bridge.md (3)
47-54: Mixer制限の明確な記載。オーディオレベルが常に0で返される一方、物理コントロール値は正常に取得できる点が明確に記載されており、実装コードとも整合しています。ユーザーにとって重要な制限事項です。
56-64: CUE制限の詳細な記載。上限15個、Memory CueとHot Cueの色転送の違い、ループCUEのoutTime正常転送等、具体的な制限事項が明確に記載されています。実機検証に基づく貴重な情報です。
109-110: トラブルシューティングの改善。同一マシン/別マシンでの動作の違いを明確に記載し、Metricsセクションの更新内容と整合しています。ユーザーが問題を切り分けやすくなる有用な更新です。
There was a problem hiding this comment.
♻️ Duplicate comments (2)
docs/wiki/PRO-DJ-LINK-Bridge.md (2)
70-70:⚠️ Potential issue | 🟡 MinorLine 70 の「未再検証」表記は、恒常的制約として読むと誤解余地があります。
未検証のまま残す場合は、検証時期/対象機種/暫定性（例: 「2026-04-12 時点の暫定情報」）を追記するか、制約一覧から切り分けた方が安全です。
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/wiki/PRO-DJ-LINK-Bridge.md` at line 70, 「未再検証」の注記が恒常的制約と誤解される恐れがあるため、該当箇所（テキスト "以下のフィールドが0で返される (未再検証)" の "未再検証" 部分）を修正してください：未検証のまま残す場合は検証日時・対象機種・暫定性を追記（例：「2026-04-12 時点、機種X/Yで未確認の暫定情報」）するか、制約一覧から切り分けて別セクション（例：「暫定/未検証情報」）に移動して誤解を避けてください。
78-84:⚠️ Potential issue | 🟡 MinorBridgeバイナリ解析の節に node-tcnet 由来情報（Line 82）が混在しています。
Line 82 の
nodeOptions記述は出所が異なるため、Bridge解析結果と node-tcnet 実装メモを分離した方が根拠のトレーサビリティが明確です。🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/wiki/PRO-DJ-LINK-Bridge.md` around lines 78 - 84, Separate the node-tcnet implementation notes from the Bridge binary analysis: remove or relocate the nodeOptions/SUPPORTS TCNCM mention from the PRO DJ LINK Bridge binary analysis section and place it into a distinct "node-tcnet implementation notes" or "Third-party implementation" section; keep the Bridge analysis focused on findings from the PRO DJ LINK Bridge.exe binary (referencing cmdOfferTCNetControl / cmdOfferTCNetText / cmdOfferTCNetKeyboard and absence of cmp 0x65) and annotate the new node-tcnet section with its source (repository/implementation) and clear provenance so readers can trace which claims come from the Bridge binary vs the node-tcnet code.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/wiki/PRO-DJ-LINK-Bridge.md`:
- Line 70: 「未再検証」の注記が恒常的制約と誤解される恐れがあるため、該当箇所（テキスト "以下のフィールドが0で返される (未再検証)" の
"未再検証" 部分）を修正してください：未検証のまま残す場合は検証日時・対象機種・暫定性を追記（例：「2026-04-12
時点、機種X/Yで未確認の暫定情報」）するか、制約一覧から切り分けて別セクション（例：「暫定/未検証情報」）に移動して誤解を避けてください。
- Around line 78-84: Separate the node-tcnet implementation notes from the
Bridge binary analysis: remove or relocate the nodeOptions/SUPPORTS TCNCM
mention from the PRO DJ LINK Bridge binary analysis section and place it into a
distinct "node-tcnet implementation notes" or "Third-party implementation"
section; keep the Bridge analysis focused on findings from the PRO DJ LINK
Bridge.exe binary (referencing cmdOfferTCNetControl / cmdOfferTCNetText /
cmdOfferTCNetKeyboard and absence of cmp 0x65) and annotate the new node-tcnet
section with its source (repository/implementation) and clear provenance so
readers can trace which claims come from the Bridge binary vs the node-tcnet
code.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: f7a37899-10dc-442e-9ae0-2901b4bdd3b0
📒 Files selected for processing (1)
docs/wiki/PRO-DJ-LINK-Bridge.md
📜 Review details
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 64
File: src/tcnet.ts:961-966
Timestamp: 2026-04-09T17:09:02.148Z
Learning: In `src/tcnet.ts` (node-tcnet, TypeScript), the TOCTOU race condition in `performBridgeOsDetection` (where an in-flight ping could overwrite `bridgeIsWindows` with a stale result after a Bridge switch) is resolved by capturing `bridgeIp = this.server?.address` at detection start and checking `this.server?.address === bridgeIp` immediately before writing to `this.bridgeIsWindows`. The maintainer (9c5s) deliberately rejected clearing `bridgeOsDetectionPromise` in `resetAuthSession` (doesn't stop internal execution) and a generation-counter approach (triggers on same-Bridge resets too) in favor of this simpler address-comparison guard.
📚 Learning: 2026-04-09T17:09:02.148Z
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 64
File: src/tcnet.ts:961-966
Timestamp: 2026-04-09T17:09:02.148Z
Learning: In `src/tcnet.ts` (node-tcnet, TypeScript), the TOCTOU race condition in `performBridgeOsDetection` (where an in-flight ping could overwrite `bridgeIsWindows` with a stale result after a Bridge switch) is resolved by capturing `bridgeIp = this.server?.address` at detection start and checking `this.server?.address === bridgeIp` immediately before writing to `this.bridgeIsWindows`. The maintainer (9c5s) deliberately rejected clearing `bridgeOsDetectionPromise` in `resetAuthSession` (doesn't stop internal execution) and a generation-counter approach (triggers on same-Bridge resets too) in favor of this simpler address-comparison guard.
Applied to files:
docs/wiki/PRO-DJ-LINK-Bridge.md
📚 Learning: 2026-03-21T05:30:31.035Z
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 2
File: src/tcnet.ts:249-255
Timestamp: 2026-03-21T05:30:31.035Z
Learning: In `src/network.ts` of the `node-tcnet` repository: `TCNetDataPacket.read()` (class defined at line 321, read() at line 330) converts the wire-format 1-based layer to 0-based by doing `this.layer = this.buffer.readUInt8(25) - 1`. In contrast, `TCNetRequestPacket.read()` (class defined at line 225, read() at line 231) does NOT subtract 1: `this.layer = this.buffer.readUInt8(25)`. Therefore, `dataPacket.layer` from a received `TCNetDataPacket` is already 0-based and correctly matches the 0-based key stored in `requestData()`. Flagging a missing `-1` in `TCNetDataPacket.read()` is a false positive.
Applied to files:
docs/wiki/PRO-DJ-LINK-Bridge.md
📚 Learning: 2026-03-21T11:31:23.742Z
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 8
File: README.MD:31-33
Timestamp: 2026-03-21T11:31:23.742Z
Learning: In `src/network.ts` of the `node-tcnet` repository: `TCNetDataPacketMetadata` (line 389) has an `info` property (not `data`). `data` property belongs to the sibling class `TCNetDataPacketMetrics` (line 352). Flagging `meta.info` in README/docs examples as wrong and suggesting `meta.data` is a false positive.
Applied to files:
docs/wiki/PRO-DJ-LINK-Bridge.md
📚 Learning: 2026-03-21T05:02:27.762Z
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 2
File: src/tcnet.ts:397-400
Timestamp: 2026-03-21T05:02:27.762Z
Learning: In the `node-tcnet` repository (`src/network.ts`, `src/tcnet.ts`), `TCNetDataPacket.write()` has no callers. `TCNetDataPacket` objects are only ever deserialized on receive paths (`read()`), never serialized and sent. The only outbound packet carrying a layer field is `TCNetRequestPacket`, constructed inside `requestData()` in `src/tcnet.ts`. Suggesting to move layer conversion logic into `TCNetDataPacket.write()` is inappropriate because that method is dead code.
Applied to files:
docs/wiki/PRO-DJ-LINK-Bridge.md
📚 Learning: 2026-03-27T08:24:18.571Z
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 50
File: src/network.ts:1010-1024
Timestamp: 2026-03-27T08:24:18.571Z
Learning: In the `node-tcnet` repository (`src/network.ts`), `Buffer.allocUnsafe()` is never used — only `Buffer.alloc()` is used throughout the codebase. Reserved fields in packet `write()` methods do not need explicit zero-initialization because `Buffer.alloc()` always zero-initializes. Suggesting defensive zero-writes for reserved packet offsets is unnecessary (YAGNI) for this codebase.
Applied to files:
docs/wiki/PRO-DJ-LINK-Bridge.md
📚 Learning: 2026-04-09T23:09:19.524Z
Learnt from: 9c5s
Repo: 9c5s/node-tcnet PR: 65
File: src/tcnet.ts:1158-1167
Timestamp: 2026-04-09T23:09:19.524Z
Learning: In `src/tcnet.ts` (node-tcnet, TypeScript), the race condition where a stale `sendAuthSequence` from an old auth generation could call `resetAuthSession` and destroy a newly-started pending auth state is resolved by: (1) adding `expectedToken: number` parameter to `sendAuthSequence` and checking `this.sessionToken !== expectedToken` at every async boundary (entry, after cmd=0 send, after 50ms wait, after prepareAuthPayload) — silently returning without calling `resetAuthSession` when stale; (2) capturing `tokenForThisAttempt` in `handleInitialAuthRequest` and only calling `resetAuthSession` in the catch block when `this.sessionToken === tokenForThisAttempt`; (3) keeping the `tokenBeforePing` guard inside `prepareAuthPayload` as a secondary defense. The maintainer (9c5s) intentionally uses this two-layer guard design.
Applied to files:
docs/wiki/PRO-DJ-LINK-Bridge.md
🔇 Additional comments (1)
docs/wiki/PRO-DJ-LINK-Bridge.md (1)
30-67: 実機検証ベースの制約追記は有用で、利用者判断に直結する改善です。Metrics/Mixer/CUE の具体的な制約と挙動が明確になり、運用時の誤解をかなり減らせる構成になっています。
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
1 participant
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.
Summary
Test plan