모드 전환 시 사소한 GUI 업데이트 버그

JRR 상점에서 C4를 400달러에 팔길래, 그냥 지나칠 수 없었습니다.

jrrshop.com/catalog/mackie-c … 951be6cc27

저는 프로그래머라서, C4를 MCU와 통합하기로 결정했습니다. Reaper 포럼에 물어봤는데 아무도 관심이 없어서, 저의 개인적인 요구에 맞는 솔루션을 직접 코딩하는 드문 호사를 누리게 되었습니다.

이 때문에 하드 코딩된 솔루션을 선택했는데, 이를 통해 VPot 스위치를 회전 메시지 대신 Bombardier 모드 스위치와 같은 기능에 사용할 수 있었고, 표면의 레이아웃/매개변수 배치에 대한 완전한 제어가 가능했습니다.

사이클링은 잘 되고 C4 LCD도 완벽하게 업데이트되지만 (I, II, III, IV, Flat) 다른 컨트롤(예를 들어 Release)이 컨트롤 서피스에서 조정될 때까지 GUI는 계속 멈춰 있다가, 그제야 모드 스위치가 올바른 위치로 이동합니다.

단순히 해당 컨트롤에 대한 GUI 이벤트 트리거가 누락된 것 같습니다.

수정: – 조금 더 복잡합니다 – 올라가는 것 (즉, 컨트롤 서피스가 모드 I에서 모드 II로 변경되는 것)은 위와 같이 작동하지만 – 내려가는 것은 이상하게 작동합니다. 3단계가 이동되었음에도 불구하고 한 번에 1단계만 점프하는 것 같습니다.

그냥 궁금해서 그러는데, VibeEQ의 주파수 선택 노브도 같은 기능을 하는지 확인해 주시겠어요?

VibeEQ 매핑을 코딩하는 데 한 시간을 보냈는데, 괜찮은 것 같습니다.

실제로 Hi Mid 섹션에 아주 미세한 버그가 있는 것 같습니다.

값을 0.8333으로 설정하면 GUI와 플러그인 자체는 6.0KHz로 설정되지만, FX 파라미터에 보고되는 문자열은 여전히 3150입니다.

값을 1.0으로 늘리면 모든 것(GUI, 플러그인, 보고되는 문자열)이 다시 8.0KHz에서 일치합니다.

끌어올립니다.

누군가 이들을 검증해 줄 수 있을까요? 아니면 제가 또다시 소프트웨어의 명백한 버그를 놓치고 평소처럼 「멍청한 프로그래머 트릭」을 쓰고 있는 걸까요? :slight_smile:

음, 저희는 확실히 우리가 해야 할 일을 하고 있다고 생각했습니다… 그리고 제가 아는 한, Vibe EQ와 Bombardier의 디텐트 노브에 대한 제어 클래스 코드는 사실상 동일합니다… 제가 설명할 수는 없을 것 같습니다. 기본적으로 두 가지 값을 추적합니다… 마우스를 누르거나 마우스 휠을 돌리는 동안만 유지되는 „표시“ 값과, 표시 값이 두 디텐트 사이의 중간 지점을 통과한 후에만 변경되는 매개변수 값입니다. 마우스를 놓으면 표시 값은 가장 가까운 사용 가능한 매개변수 값으로 „스냅“되어야 합니다.

노브를 돌릴 때 플러그인에 어떤 이벤트를 보내고 있습니까?

Scott

그것은 이쪽에서 제가 하는 어리석은 짓일 가능성이 더 높습니다 :slight_smile:

기본적으로 저는 컨트롤 서페이스에서 플러그인을 제어하고 있습니다:

jrrshop.com/catalog/mackie-c … 951be6cc27

사진을 확대해 보세요 – 어떤 느낌인지 아실 겁니다.

불연속 값 유형(예: Bombardier 모드)의 경우, 서페이스의 32개 VPot(로터리 인코더)에도 스위치 동작이 있다는 점을 활용합니다. VPot 상단을 누름으로써 작동하며, 일반적인 멤브레인 모멘터리 스위치입니다.

각 누름에 따라 사용 가능한 값을 순환하기 위해 테이블 조회 기능을 사용합니다. 이는 로터리 인코더를 사용하여 불연속 값을 설정하는 것보다 훨씬 깨끗하고 예측 가능합니다:

FXSwitchParameter *BombardierMode = new FXSwitchParameter("Mode", 12, this); BombardierMode->numDiscreetValues = 5; BombardierMode->discreetValues[0] = 0.0; BombardierMode->discreetValues[1] = 0.25; BombardierMode->discreetValues[2] = 0.5; BombardierMode->discreetValues[3] = 0.75; BombardierMode->discreetValues[4] = 1.0; Bombardier->Add(BombardierMode)

또는 Vibe EQ의 경우:

FXComboSwitchParameter *VibeEQMF2Freq = new FXComboSwitchParameter("MF 2 Freq", "", 5, this); VibeEQMF2Freq->numDiscreetValues = 7; VibeEQMF2Freq->discreetValues[0] = 0.0; VibeEQMF2Freq->discreetValues[1] = 0.16; VibeEQMF2Freq->discreetValues[2] = 0.33; VibeEQMF2Freq->discreetValues[3] = 0.5; VibeEQMF2Freq->discreetValues[4] = 0.66; VibeEQMF2Freq->discreetValues[5] = 0.83333; VibeEQMF2Freq->discreetValues[6] = 1.0; VibeEQ->Add(VibeEQMF2Freq)

이 접근 방식은 위에 언급된 두 부분을 제외하고 Bombardier, Rocket, 1973 및 Vibe EQ의 모든 곳에서 완벽하게 작동합니다.

저는 Reaper SDK 호출에서 디버거에 중단점을 설정하여 파라미터 값을 얻었습니다:

value = TrackFX_GetParam(trackSelectedForC4, FXInstances[i].index, currentFXParameter->index, &min, &max);

그리고 다음도 사용합니다:

TrackFX_SetParam(trackSelectedForC4, FXIndex, index, parameterValue); TrackFX_FormatParamValue(trackSelectedForC4, FXIndex, index, parameterValue, parameterValueString, sizeof(parameterValueString));

예를 들어 Vibe EQ의 경우:

값을 0.8333으로 설정하면 GUI와 플러그인 자체는 6.0KHz로 설정되지만, 위 코드에서 「parameterValueString」으로 보고되는 문자열은 여전히 3150입니다.

값을 1.0으로 더 올리면 모든 것(GUI, 플러그인, 보고된 문자열)이 8.0KHz에서 다시 정렬됩니다.

다른 모든 값은 완벽하게 작동합니다.

Bombardier의 동작은 이전 게시물에 언급되어 있습니다.

이쪽에서 제가 뭔가 잘못하고 있는 건 아닌지 궁금할 뿐입니다.

음…서식 지정된 매개변수 문자열이라면, 그건 아마 “내” 코드보다는 IPlug 코드에 있을 겁니다…컨트롤을 조작할 때 값 문자열을 명시적으로 설정하지 않습니다. 그건 IPlug에서 상속된 동작입니다.

컨트롤의 GUI 표현이 변경되지 않는다는 점에 대해…그건 컨트롤이 더럽다고 표시되지 않아서일 것입니다…다시 그려야 할 필요성을 모르는 것이죠. schwa에게 확인하여 IPlug의 결함인지, 아니면 (더 가능성 있는 것은) 제 뇌의 결함인지 알아보겠습니다. :slight_smile:

Scott

알겠습니다, 확인해 주셔서 감사합니다.

저는 IPlug 코드에 익숙하지 않고 IPlug 코드와 사용자 코드의 경계가 어디인지 몰랐습니다.

이 한 가지 경우에만 나타나는 것이 이상하게 느껴지지만, 여전히 제가 뭔가 잘못하고 있는 것일 수도 있습니다.

RE: GUI 표현 — 네, 더티 플래그가 설정되지 않았거나 이벤트가 트리거되지 않은 것 같은 느낌입니다.

음, IPlug 코드는 Cockos 웹사이트의 WDL 라이브러리의 일부로 무료로 제공됩니다. 참조용으로 가져오고 싶으면 그렇게 할 수 있습니다. 유틸리티/그래픽을 위해서는 WDL의 나머지 부분을 사용하는 것이 훨씬 좋습니다. 주파수 및 모드 노브를 처리하는 컨트롤은 실제로 제가 작성한 클래스(IDetentKnob)로, 기본 IPlug 클래스 IKnobMultiControl을 상속받습니다. IDetentKnob은 IPlug의 일부는 아니지만, 언젠가 프로젝트에 다시 기여할 수도 있습니다.

Scott