Pequeno bug na atualização da GUI no Seletor de Modo

A loja JRR está vendendo C4s por US$ 400, não resisti.

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

Sou programador, então decidi integrar o C4 ao meu MCU — perguntei no fórum do Reaper — zero interesse — então tenho o raro luxo de criar uma solução personalizada que atenda às minhas necessidades pessoais.

Por causa disso, optei por uma solução “hard coded” (codificada manualmente), o que me permite usar os interruptores VPot em vez das mensagens rotativas para coisas como o interruptor Bombardier Mode, além de ter controle completo sobre o layout / posicionamento dos parâmetros na superfície.

Consigo alternar perfeitamente e o LCD do C4 atualiza-se perfeitamente (I, II, III, IV, Flat), mas a GUI permanece travada, até que qualquer outro controle (digamos, Release) seja ajustado a partir da superfície de controle, então o “Mode Switch” (Interruptor de Modo) salta para a posição correta.

Parece ser uma questão simples de um gatilho de evento da GUI ausente apenas naquele controle.

Edição: — É um pouco mais complicado — subir (ou seja, a superfície de controle muda do Modo I para o Modo II) se comporta como acima — descer é estranho, parece saltar apenas 1 passo por vez, mesmo que possa ter sido movido 3 passos.

Por curiosidade, você poderia ver se os botões de seleção de frequência do VibeEQ fazem o mesmo?

Acabei de passar uma hora codificando o mapeamento do VibeEQ, parece que está tudo bem.

Na verdade, parece haver um bug muito pequeno na seção Hi Mid.

Definir o valor para 0.8333 ajusta a GUI e o próprio plugin para 6.0KHz, mas o string relatado no parâmetro FX ainda é 3150.

Se você aumentar para 1.0, tudo (a GUI, o plugin, o string relatado) se alinha novamente em 8.0KHz.

Bump,

Alguém pode verificar isso, ou estou fazendo minha usual trapalhada de programador “truques” novamente, tendo perdido mais um bug óbvio no meu software? :slight_smile:

Bem, eu certamente PENSEI que tínhamos ele fazendo o que deveria… e até onde sei, o código da classe de controle para os botões de detent em Vibe EQ e Bombardier são efetivamente idênticos… não sei se consigo explicar. Basicamente, ele rastreia dois valores… o valor de “exibição” que é mantido apenas enquanto o mouse está pressionado ou a roda do mouse está sendo girada, e o valor do parâmetro, que só muda quando o valor de exibição passa do ponto médio entre dois detents. Assim que você solta o mouse, o valor de exibição deve “voltar” para o valor do parâmetro disponível mais próximo.

Que eventos você está enviando para o plug-in quando gira os botões?

Scott

É mais do que provável que seja algo estúpido que eu esteja fazendo aqui :slight_smile:

Basicamente, estou controlando os plugins a partir de uma superfície de controle:

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

Aumente a imagem – você terá uma ideia.

Para os tipos de valor discreto (por exemplo, Modo Bombardier), aproveito o fato de que os 32 VPots (encoders rotativos) na superfície também possuem comportamento de chave – você pressiona a parte superior do VPot – é um momento de membrana típico.

Eu então uso a busca em tabela para alternar entre os valores disponíveis a cada pressionamento – é muito mais limpo e previsível do que usar o encoder rotativo para definir os valores discretos:

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)

ou no caso do 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)

Essa abordagem funciona perfeitamente no Bombardier, Rocket, 1973 e Vibe EQ em todos os lugares, exceto nos 2 trechos citados acima.

Obtive os valores dos parâmetros quebrando o depurador na chamada da Reaper SDK:

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

e também uso:

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

Então, por exemplo, no Vibe EQ:

Configurar o valor para 0.8333 define a GUI e o próprio plugin para 6.0KHz, mas a string relatada em “parameterValueString” no código acima ainda é 3150.

Se você então aumentar para 1.0, tudo (a GUI, o plugin, a string relatada) se alinha novamente em 8.0KHz.

Todos os outros valores funcionam perfeitamente.

O comportamento do Bombardier é observado em uma postagem anterior.

Apenas curioso para saber se é algo que estou fazendo de errado aqui.

Hã… se for apenas a string de parâmetro formatada, então isso provavelmente está no código do IPlug, e não no “meu” código… não se define explicitamente as strings de valor ao manipular os controles; isso é um comportamento herdado do IPlug.

Re: a representação da GUI dos controles não está mudando… isso teria que ser o controle não sendo marcado como sujo… não sabendo que precisa redesenhar. Verificarei com schwa e verei se isso é um defeito no IPlug, ou (mais provavelmente) um defeito no meu cérebro. :slight_smile:

Scott

Legal, obrigado por analisar.

Não estou familiarizado com o código IPlug e não sabia onde estava a divisão entre ele e seu código.

Parece estranho que ele apareça somente neste caso, ainda pode ser algo que estou fazendo de errado aqui.

RE: representação da GUI – sim, parece exatamente um sinalizador de “sujo” que não foi definido, ou um evento que não dispara, esse tipo de coisa.

Bem, o código do IPlug está disponível gratuitamente como parte das bibliotecas wdl no site da Cockos, caso você queira pegá-lo apenas para referência. Você poderia fazer algo muito pior para um monte de utilidades/gráficos do que usar o resto do wdl também… O controle que faz os botões de frequência e modo são, na verdade, uma classe que escrevi (IDetentKnob) que herdam da classe IPlug IKnobMultiControl. IDetentKnob não faz parte do IPlug, embora… eu possa contribuir com ele para o projeto em algum momento.

Scott