# Fluid Ardule 진행 마일스톤 정리 (2026-03-29) ## 개요 이번 단계에서는 Fluid Ardule 프로젝트의 기존 안정 버전을 유지하면서, 로터리 인코더 기반 CC 제어 기능을 본 코드에 통합하기 위한 핵심 검증과 1차 통합을 진행하였다. 특히 **인코더 하드웨어 자체의 정상 여부**, **디코딩 방식**, **감도 배수**, **UNO–Pi 간 CC 프로토콜**, **기존 Pi 메인 스크립트와의 연동**, **과도한 로그/화면 갱신 억제**를 중심으로 구조를 정리하였다. --- ## 1. 기존 안정 기반의 재확인 이번 작업은 다음의 기존 안정 기반 위에서 진행되었다. - Raspberry Pi 3B + Arduino Uno 구조 유지 - Uno는 UI 및 입력 처리 담당 - Pi는 FluidSynth, MIDI 라우팅, 상태 관리 담당 - Uno ↔ Pi는 USB 시리얼 통신 사용 - HELLO / UNO_READY / heartbeat(HB) 기반 자동 재링크 구조 유지 - DOWN 롱프레스 PANIC, Power / SoundFont / Pot volume 기능 유지 - 기존 Pi 메인 스크립트의 DAC 감지, MIDI keyboard strict 감지, TFT 상태 출력, systemd 운용 기반 유지 즉, 이번 단계는 구조를 뒤엎는 개발이 아니라, **기존 안정 루프 위에 인코더/CC 기능을 얹는 방향**으로 진행되었다. --- ## 2. 인코더 하드웨어 진단 완료 ### 2-1. 독립 진단 펌웨어 작성 기존 UI/상태머신과 분리된 **인코더 전용 진단용 펌웨어**({{:fluidcanvas_r2pi:arduino_uno_260329b_encoder_diag_any_gain_toggle.zip|다운로드}})를 작성하여 다음 항목을 직접 확인하였다. - CLK = D2 - DT = D3 - SW = A1 - LCD Keypad Shield의 버튼은 A0 - 시리얼 모니터와 LCD를 통해 encoder 신호 패턴 확인 - 방향(CW/CCW)과 버튼(SW) 인식 확인 ### 2-2. 진단 결과 진단 결과 다음이 확 인되었다. - 인코더 방향 인식은 정확함 - 스위치 입력도 정상 동작함 - 하드웨어 불량 가능성은 낮음 - 문제는 부품 자체가 아니라 **디코딩 방식과 감도 설정**에 있었음 이는 이후 본 코드 통합 방향을 결정하는 중요한 근거가 되었다. --- ## 3. 인코더 디코딩 방식 확정 ### 3-1. FALL 방식과 ANY 방식 비교 진단용 펌웨어에서 다음 두 가지 방식을 비교하였다. - **FALL mode**: A의 falling edge만 사용 - **ANY mode**: A의 rising + falling edge 모두 사용 비교 결과, FALL 방식은 반응이 둔하고 체감 해상도가 부족하였으며, **ANY 방식이 훨씬 자연스럽고 사용감이 좋음**이 확인되었다. ### 3-2. 최종 채택 방식 따라서 본 개발용 인코더 해석 방식은 다음으로 확정하였다. - **ANY edge decode** - 즉, `CLK(A)`의 변화 전체를 사용 - 방향 판정은 `A/B` 관계로 계산 이 결정은 향후 CC 조절 UI의 기본 입력 엔진으로 사용된다. --- ## 4. 인코더 감도 배수 확정 ### 4-1. 감도 테스트 펌웨어 작성 ANY 방식 고정 후, 감도 배수를 비교하기 위해 다음 테스트를 수행하였다. - x1 - x2 - x3 - x4 SELECT 버튼으로 배수를 바꾸며 1회전당 logical position 변화량과 체감 조작감을 비교하였다. ### 4-2. 감도 결론 테스트 결과: - x1: 지나치게 둔함 - x2: 개선되지만 약간 답답함 - **x3: 가장 균형이 좋음** - x4: 빠르지만 다소 과민할 가능성 있음 따라서 현재 통합본에서의 기본 감도는 다음으로 확정되었다. - **인코더 배수 = x3** 즉, 본 코드에는 다음 정책이 적용되었다. - 디코딩: ANY edge - gain: x3 --- ## 5. CC Control 기능의 1차 통합 ### 5-1. UNO 측 기존 안정본에 다음 기능을 추가하였다. - `UI_CC_CONTROL` 상태 추가 - HOME에서 `SELECT short`로 CC Control 진입 - CC 항목: - CC10 Pan - CC91 Reverb - CC93 Chorus - CC Control에서: - 인코더 회전 → 현재 CC 값 증감 - SELECT short → 다음 CC 항목 - LEFT → HOME 복귀 - Uno → Pi: - `CCDELTA::` 전송 - Pi → Uno: - `CCVAL::` 수신 및 LCD 반영 ### 5-2. Pi 측 기존 메인 스크립트에 다음 기능을 추가하였다. - `CCDELTA` 파싱 - CC 상태값 저장(`cc_state`) - 0~127 범위 clamp - FluidSynth에 실제 CC 전송 - `CCVAL`을 Uno로 회신 이를 통해 Uno는 UI/입력 처리만 맡고, Pi는 실제 상태 유지와 MIDI 반영을 맡는 원칙이 유지되었다. --- ## 6. HELLO 기반 부팅/재링크 흐름 정비 이번 단계에서는 Uno 펌웨어가 Pi의 시리얼 접속 요청 없이 자동 진행되지 않는 점도 반영하여, **Pi 스크립트가 HELLO를 명시적으로 보내는 구조**를 다시 정리하였다. 정상 흐름은 다음과 같다. 1. Pi가 시리얼 포트 open 2. Uno auto-reset 3. Pi가 `HELLO` 송신 4. Uno가 `UNO_READY` 응답 5. Pi가 상태 스냅샷 및 heartbeat 송신 시작 6. Uno가 HOME 화면으로 진입 즉, 이번 통합본은 **기존 full service 구조와 맞는 HELLO 기반 재연결 흐름**을 전제로 완성되었다. --- ## 7. Pi 메인 스크립트의 “quiet mode” 정리 기존 Pi 스크립트는 기능상으로는 잘 동작했지만, 콘솔 로그와 TFT 갱신이 지나치게 잦아 실제 운용 시 불필요하게 시끄러운 문제가 있었다. 이번 단계에서 이를 다음과 같이 정리하였다. ### 7-1. MIDI 후보 로그 억제 - `MIDI candidates:` 로그를 매 스캔마다 출력하지 않고 - **후보 목록이 바뀔 때만 출력**하도록 수정 ### 7-2. 주기 완화 - Audio scan 주기 완화 - MIDI scan 주기 완화 이를 통해 동일 상태에서 반복 로그가 크게 줄어들었다. ### 7-3. TFT 갱신 최적화 - TFT 화면을 매 tick마다 다시 그리지 않고 - **표시 상태 스냅샷이 바뀔 때만 갱신**하도록 수정 ### 7-4. fbi 출력 억제 - `using "DejaVu Sans Mono..."` 같은 `fbi` 출력이 콘솔을 어지럽히지 않도록 - stdout/stderr를 숨기도록 조정 그 결과, 이제 Pi 쪽은 **실전 운용에 가까운 조용한 상태 보고 구조**를 갖추게 되었다. --- ## 8. 이번 단계의 의미 이번 단계는 단순히 인코더 하나를 붙인 것이 아니라, 다음을 확정한 마일스톤이다. - 인코더 하드웨어 정상 판정 완료 - 디코딩 방식(ANY edge) 확정 - 감도 배수(x3) 확정 - Uno–Pi 간 CC 프로토콜 확정 - 기존 Pi 메인 스크립트와의 연동 구조 완성 - 과도한 로그/TFT 갱신 억제 - 기존 안정 루프를 유지한 채 기능 확장 가능성 확인 즉, 이제 Fluid Ardule은 **“기존 안정 베이스 위에 새로운 조작 요소를 안전하게 통합할 수 있는 단계”**에 들어섰다고 볼 수 있다. --- ## 9. 현재 상태의 한 줄 요약 > **UNO–Pi 안정 구조를 유지한 채, 인코더 기반 CC 제어의 입력 해석 방식과 감도를 확정하고, Pi 메인 스크립트까지 포함한 1차 통합을 완료하였다.** --- ## 10. 다음 단계 제안 다음 개발은 다음 순서로 이어가는 것이 적절하다. 1. 현재 x3 고정 감도를 계속 쓸지 최종 확인 2. CC 화면의 LCD 표현 개선 3. 필요 시 가속(acceleration) 방식 검토 4. 기존 워킹 코드 기준으로 SoundFont / Power / CC의 UX 정교화 5. 최종 systemd 배포 구조 반영 --- 작성일: 2026-03-29