Error menor de actualización de la GUI en el cambio de modo

JRR shop está liquidando los C4 por 400 $, no me pude resistir.

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

Soy programador, así que decidí integrar el C4 con mi MCU —pregunté en el foro de Reaper— cero interés— así que tengo el raro lujo de codificar una solución a medida que se adapte a mis necesidades personales.

Debido a esto, opté por una solución codificada, lo que me permite usar los interruptores VPot en lugar de los mensajes rotatorios para cosas como el interruptor de Modo Bombardier, además de tener control total sobre el diseño/colocación de parámetros en la superficie.

Puedo recorrer el ciclo perfectamente y la pantalla LCD del C4 se actualiza perfectamente (I, II, III, IV, Flat), pero la GUI permanece atascada, hasta que cualquier otro control (digamos, Release) se ajusta desde la superficie de control, entonces el Interruptor de Modo salta a la posición correcta.

Parece que es un simple caso de un disparador de evento GUI faltante solo en ese control.

Editar: —Es un poco más complicado— subir (es decir, la superficie de control cambia de Modo I a Modo II) se comporta como se describió anteriormente— bajar es extraño, parece saltar solo 1 paso a la vez, aunque puede haberse movido 3 pasos

Solo por curiosidad, ¿podrías ver si las perillas de selección de frecuencia de VibeEQ hacen lo mismo?

Acabo de pasar una hora codificando el mapeo de VibeEQ, parece que está bien.

En realidad, parece haber un error muy leve en la sección Hi Mid.

Al establecer el valor en 0.8333, la GUI y el propio plugin se configuran a 6.0KHz, pero la cadena informada en el parámetro FX sigue siendo 3150.

Si luego se aumenta a 1.0, todo (la GUI, el plugin, la cadena informada) vuelve a coincidir en 8.0KHz.

Bump,

¿Alguien puede verificar esto, o estoy de nuevo con mis acostumbrados «trucos de programador estúpidos», habiendo pasado por alto otro error obvio en mi software? :slight_smile:

Bueno, ciertamente PENSÉ que lo teníamos haciendo lo que se supone que debe hacer… y hasta donde sé, el código de la clase de control para los mandos de retención en Vibe EQ y Bombardier es efectivamente idéntico… No estoy seguro de poder explicarlo. Básicamente rastrea dos valores… el valor de «visualización» que solo se mantiene mientras se presiona el ratón o se gira la rueda del ratón, y el valor del parámetro, que solo cambia una vez que el valor de visualización pasa el punto medio entre dos retenciones. Una vez que sueltas el ratón, el valor de visualización debería «volver» al valor de parámetro disponible más cercano.

¿Qué eventos terminas enviando al plugin cuando giras los mandos?

Scott

Es más que probable que sea una tontería lo que estoy haciendo aquí :slight_smile:

Básicamente, estoy controlando los plugins desde una superficie de control:

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

expande la imagen – te harás una idea.

Para los tipos de valores discretos (por ejemplo, Modo Bombardier), aprovecho el hecho de que los 32 VPots (codificadores rotatorios) de la superficie también tienen comportamiento de interruptor – presionas la parte superior del VPot – es un momentáneo de membrana típico.

Luego uso la búsqueda en tabla para recorrer los valores disponibles con cada pulsación – es mucho más limpio y predecible que usar el codificador rotatorio para establecer los 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)

o en el caso del 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)

Este enfoque funciona perfectamente en Bombardier, Rocket, 1973 y Vibe EQ en todas partes, excepto en los 2 trozos citados anteriormente.

Obtuve los valores de los parámetros al establecer un punto de interrupción en el depurador en la llamada al SDK de Reaper:

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

y también utilizo:

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

Así, por ejemplo, en el Vibe EQ:

Establecer el valor en 0.8333 configura la GUI y el plugin mismo en 6.0KHz, pero la cadena reportada en “parameterValueString” en el código anterior sigue siendo 3150.

Si luego se aumenta a 1.0, todo (la GUI, el plugin, la cadena reportada) vuelve a alinearse en 8.0KHz.

Todos los demás valores funcionan perfectamente.

El comportamiento del Bombardier se menciona en un post anterior.

Solo tengo curiosidad por saber si es algo que estoy haciendo mal en este extremo.

Vaya… si se trata solo de la cadena de parámetros formateada, entonces probablemente esté en el código de IPlug en lugar de en “mi” código… uno no establece explícitamente las cadenas de valor al manipular los controles; ese es un comportamiento heredado de IPlug.

Re: la representación gráfica de los controles no cambia… eso tendría que ser que el control no se marque como sucio… no saber que necesita redibujarse. Preguntaré a schwa y veré si es un defecto en IPlug, o (más probablemente) un defecto en mi cerebro. :slight_smile:

Scott

Genial, gracias por investigarlo.

No estoy familiarizado con el código de IPlug y no sabía dónde estaba la división entre este y tu código.

Parece extraño que solo se presente en este caso, podría ser algo que estoy haciendo mal aquí.

RE: Representación de la interfaz gráfica de usuario - sí, se siente exactamente como si un indicador de estado modificado no se hubiera establecido, o un evento no se hubiera disparado, ese tipo de cosas.

Bueno, el código de IPlug está disponible gratuitamente como parte de las librerías wdl en la página web de Cockos, por si quieres tomarlo solo como referencia. También podrías hacer cosas mucho peores para un montón de utilidades/gráficos que usar el resto de wdl… El control que hace las perillas de frecuencia y modo es en realidad una clase que escribí (IDetentKnob) que hereda de la clase IKnobMultiControl estándar de IPlug. IDetentKnob no forma parte de IPlug, sin embargo… aunque podría contribuirlo al proyecto en algún momento.

Scott