DJ の楽曲変化を Pro DJ Link と OSC で受け取り、客側画面・店側画面・注文状態をひとつのランタイムに同期する。DJ Cocktail Engine は、静的メニューではなく、音楽イベントをトリガーにしてその場のカクテルを生成・提示するホスピタリティシステムである。
システムは Track Input、Recipe / Order Backend、Presentation、External Notification の 4 層で構成される。役割を分離しながら、現在曲と現在オーダーを単一の runtime state に集約する。
DJ 側システムから Pro DJ Link Bridge 経由で OSC を受信し、曲切り替え・補助メタデータ・atmosphere profile を区別して扱う。
Node.js + Express + SQLite の単一プロセスが、トラック状態・レシピ保存・注文進行・外部通知をまとめて管理する。
客側・店側・管理画面の 3 つの Web UI と、URL を切り替えられる iOS wrapper が presentation を担う。
システム外部への連携は OSC broadcast で処理し、新規カクテル生成と注文発生を別イベントとして発火する。
重要なのは、トラックイベントが単なる表示更新ではなく、レシピの差し替えとオーダー進行の起点になっていること。SSE の `state.changed` が、全フロントの同期単位になる。
曲が切り替わった瞬間に、新しい楽曲文脈へレシピを切り替えるための中心フロー。
現在曲名・アーティスト・BPM の補助更新を担当し、レシピ変更は行わない。
trackProfile の atmosphereSummary を、現在表示中トラックと一致する場合だけ mood として反映する。
客側で注文された 1 件を、店側の進行管理と完了通知へ接続する。
フロント同期は SSE、DJ 入力と外部通知は OSC、操作系 API は HTTP に分離している。単一の Node.js runtime がそれらを束ね、今フロントに見せるべき state を確定する。
レシピ CRUD、注文作成、進行更新、現在 state 取得に使う。
recipes orders app_state双方向通信を持たずに、サーバ主導で state.changed を配信する。
event: state.changed target: guest / method / adminDJ システムの曲変化を受ける入口。既定の受信ポートは 29001。
osc.receivePort 29001新規カクテルと注文発生を broadcast で外部システムへ通知する。
osc.broadcastAddress 255.255.255.255:29000現状は曲変化で既存レシピをランダム選択しているが、設計上は trackChanged を受けてその曲専用のレシピを生成し、selectedRecipe を差し替えるべきである。
`trackChanged` 時の本来の recipe generation が未接続のため、既存の有効レシピ群からランダム選択する暫定処理が入っている。
trackChanged を受けたら曲情報を正規化し、その曲に対応する新規レシピ生成を実行して保存し、selectedRecipeId を新しい 1 杯へ向ける。
UI スクリーンショットは hero に集約し、このセクションでは会場で実際に設置・運用されていた様子だけを見る。同じ画像を繰り返し並べるのではなく、実使用の状態を優先して見せる。
Track event は表示更新のトリガーであり、Recipe はその時点の音楽文脈に従って更新される。客画面は「一覧」ではなく「今この瞬間の一杯」を見せ、店側画面は「今作るべきもの」を見せる。
selectedRecipe、currentTrack、activeOrder を単一の state として束ねることで、客側・店側・外部通知の全てが同期する。個別画面の装飾より、state の一貫性が体験を決める。
この公開ページはシステム概要に特化している。実装や運用の追加資料が必要な場合は、project listing から関連プロジェクトへ戻って参照する。
Return To Installation Projects
