Table of Contents

Fluid Ardule 진행 마일스톤 정리 (2026-03-29)

개요

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


1. 기존 안정 기반의 재확인

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

즉, 이번 단계는 구조를 뒤엎는 개발이 아니라, 기존 안정 루프 위에 인코더/CC 기능을 얹는 방향으로 진행되었다.


2. 인코더 하드웨어 진단 완료

2-1. 독립 진단 펌웨어

작성

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

2-2. 진단 결과

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

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


3. 인코더 디코딩 방식 확정

3-1. FALL 방식과 ANY 방식 비교

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

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

3-2. 최종 채택 방식

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

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


4. 인코더 감도 배수 확정

4-1. 감도 테스트 펌웨어 작성

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

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

4-2. 감도 결론

테스트 결과:

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

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


5. CC Control 기능의 1차 통합

5-1. UNO 측

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

5-2. Pi 측

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

이를 통해 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 후보 로그 억제

7-2. 주기 완화

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

7-3. TFT 갱신 최적화

7-4. fbi 출력 억제

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


8. 이번 단계의 의미

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

즉, 이제 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