이번 단계에서는 Fluid Ardule 프로젝트의 기존 안정 버전을 유지하면서, 로터리 인코더 기반 CC 제어 기능을 본 코드에 통합하기 위한 핵심 검증과 1차 통합을 진행하였다.
특히 인코더 하드웨어 자체의 정상 여부, 디코딩 방식, 감도 배수, UNO–Pi 간 CC 프로토콜, 기존 Pi 메인 스크립트와의 연동, 과도한 로그/화면 갱신 억제를 중심으로 구조를 정리하였다.

이번 작업은 다음의 기존 안정 기반 위에서 진행되었다.

• 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 기능을 얹는 방향으로 진행되었다.

기존 UI/상태머신과 분리된 인코더 전용 진단용 펌웨어를 작성하여 다음 항목을 직접 확인하였다.

• CLK = D2
• DT = D3
• SW = A1
• LCD Keypad Shield의 버튼은 A0
• 시리얼 모니터와 LCD를 통해 encoder 신호 패턴 확인
• 방향(CW/CCW)과 버튼(SW) 인식 확인

진단 결과 다음이 확인되었다.

• 인코더 방향 인식은 정확함
• 스위치 입력도 정상 동작함
• 하드웨어 불량 가능성은 낮음
• 문제는 부품 자체가 아니라 디코딩 방식과 감도 설정에 있었음

이는 이후 본 코드 통합 방향을 결정하는 중요한 근거가 되었다.

진단용 펌웨어에서 다음 두 가지 방식을 비교하였다.

• FALL mode: A의 falling edge만 사용
• ANY mode: A의 rising + falling edge 모두 사용

비교 결과, FALL 방식은 반응이 둔하고 체감 해상도가 부족하였으며,
ANY 방식이 훨씬 자연스럽고 사용감이 좋음이 확인되었다.

따라서 본 개발용 인코더 해석 방식은 다음으로 확정하였다.

• ANY edge decode
• 즉, CLK(A)의 변화 전체를 사용
• 방향 판정은 A/B 관계로 계산

이 결정은 향후 CC 조절 UI의 기본 입력 엔진으로 사용된다.

ANY 방식 고정 후, 감도 배수를 비교하기 위해 다음 테스트를 수행하였다.

• x1
• x2
• x3
• x4

SELECT 버튼으로 배수를 바꾸며 1회전당 logical position 변화량과 체감 조작감을 비교하였다.

테스트 결과:

• x1: 지나치게 둔함
• x2: 개선되지만 약간 답답함
• x3: 가장 균형이 좋음
• x4: 빠르지만 다소 과민할 가능성 있음

따라서 현재 통합본에서의 기본 감도는 다음으로 확정되었다.

• 인코더 배수 = x3

즉, 본 코드에는 다음 정책이 적용되었다.

• 디코딩: ANY edge
• gain: x3

기존 안정본에 다음 기능을 추가하였다.

• 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:<cc>:<delta> 전송
• Pi → Uno:
  • CCVAL:<cc>:<value> 수신 및 LCD 반영

기존 메인 스크립트에 다음 기능을 추가하였다.

• CCDELTA 파싱
• CC 상태값 저장(cc_state)
• 0~127 범위 clamp
• FluidSynth에 실제 CC 전송
• CCVAL을 Uno로 회신

이를 통해 Uno는 UI/입력 처리만 맡고, Pi는 실제 상태 유지와 MIDI 반영을 맡는 원칙이 유지되었다.

이번 단계에서는 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 기반 재연결 흐름을 전제로 완성되었다.

기존 Pi 스크립트는 기능상으로는 잘 동작했지만, 콘솔 로그와 TFT 갱신이 지나치게 잦아 실제 운용 시 불필요하게 시끄러운 문제가 있었다.

이번 단계에서 이를 다음과 같이 정리하였다.

• MIDI candidates: 로그를 매 스캔마다 출력하지 않고
• 후보 목록이 바뀔 때만 출력하도록 수정

• Audio scan 주기 완화
• MIDI scan 주기 완화

이를 통해 동일 상태에서 반복 로그가 크게 줄어들었다.

• TFT 화면을 매 tick마다 다시 그리지 않고
• 표시 상태 스냅샷이 바뀔 때만 갱신하도록 수정

• using "DejaVu Sans Mono..." 같은 fbi 출력이 콘솔을 어지럽히지 않도록
• stdout/stderr를 숨기도록 조정

그 결과, 이제 Pi 쪽은 실전 운용에 가까운 조용한 상태 보고 구조를 갖추게 되었다.

이번 단계는 단순히 인코더 하나를 붙인 것이 아니라, 다음을 확정한 마일스톤이다.

• 인코더 하드웨어 정상 판정 완료
• 디코딩 방식(ANY edge) 확정
• 감도 배수(x3) 확정
• Uno–Pi 간 CC 프로토콜 확정
• 기존 Pi 메인 스크립트와의 연동 구조 완성
• 과도한 로그/TFT 갱신 억제
• 기존 안정 루프를 유지한 채 기능 확장 가능성 확인

즉, 이제 Fluid Ardule은 “기존 안정 베이스 위에 새로운 조작 요소를 안전하게 통합할 수 있는 단계”에 들어섰다고 볼 수 있다.

UNO–Pi 안정 구조를 유지한 채, 인코더 기반 CC 제어의 입력 해석 방식과 감도를 확정하고, Pi 메인 스크립트까지 포함한 1차 통합을 완료하였다.

다음 개발은 다음 순서로 이어가는 것이 적절하다.

1. 현재 x3 고정 감도를 계속 쓸지 최종 확인
2. CC 화면의 LCD 표현 개선
3. 필요 시 가속(acceleration) 방식 검토
4. 기존 워킹 코드 기준으로 SoundFont / Power / CC의 UX 정교화
5. 최종 systemd 배포 구조 반영

작성일: 2026-03-29