Bug de mise à jour GUI mineur dans Mode Switch

Stillwell Audio Plugins Bombardier
1

JRR shop brade les C4 à 400 $, je n’ai pas pu résister.

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

Je suis programmeur, alors j’ai décidé d’intégrer le C4 à mon MCU — j’ai posé la question sur le forum Reaper — zéro intérêt — j’ai donc le rare luxe de coder une solution personnalisée qui répond à mes besoins personnels.

À cause de cela, j’ai opté pour une solution codée en dur, ce qui me permet d’utiliser les commutateurs VPot au lieu des messages rotatifs pour des choses comme le commutateur de mode Bombardier, ainsi que d’avoir un contrôle complet sur la disposition / le placement des paramètres à la surface.

Je peux faire défiler sans problème et l’écran LCD du C4 se met à jour parfaitement (I, II, III, IV, Plat) mais l’interface graphique reste bloquée, jusqu’à ce que tout autre contrôle (disons Release) soit ajusté depuis la surface de contrôle, puis le commutateur de mode saute à la bonne position.

Cela semble être simplement un déclencheur d’événement GUI manquant sur ce seul contrôle.

Edit : — C’est un peu plus compliqué — monter (c’est-à-dire que la surface de contrôle passe du mode I au mode II) se comporte comme ci-dessus — descendre est étrange, cela semble sauter seulement 1 étape à la fois, même si cela a pu être déplacé de 3 étapes

2

Juste par curiosité, pourriez-vous vérifier si les potentiomètres de sélection de fréquence de VibeEQ font la même chose?

3

Je viens de passer une heure à coder le mappage VibeEQ, il semble bien fonctionner.

4

Il semble en fait y avoir un léger bug dans la section Hi Mid.

Définir la valeur sur 0,8333 règle l’interface graphique et le plugin sur 6,0 KHz, mais la chaîne signalée dans le paramètre FX est toujours 3150.

Si vous l’augmentez ensuite à 1,0, tout (l’interface graphique, le plug-in, la chaîne signalée) s’aligne à nouveau sur 8,0 KHz.

5

Petit coup de pouce,

Quelqu’un peut-il vérifier ceci, ou c’est encore une de mes «astuces de programmeur stupide» habituelles, ayant raté un autre bogue évident dans mon logiciel :slight_smile:

6

Eh bien, je PENSE certainement que nous lui avions fait faire ce qu’il était censé faire… et d’après ce que je sais, le code de la classe de contrôle pour les boutons à cran d’arrêt de Vibe EQ et Bombardier est effectivement identique… je ne suis pas sûr de pouvoir l’expliquer. Il suit en fait deux valeurs… la valeur « affichée » qui n’est conservée que lorsque la souris est enfoncée ou que la molette de la souris est tournée, et la valeur du paramètre, qui ne change qu’une fois que la valeur affichée dépasse la moitié du chemin entre deux crans d’arrêt. Une fois que vous relâchez la souris, la valeur d’affichage devrait « revenir » à la valeur de paramètre disponible la plus proche.

Quels événements finissez-vous par envoyer au plugin lorsque vous tournez les boutons ?

Scott

7

C’est plus que probablement quelque chose de stupide que je fais de mon côté :slight_smile:

En gros, je contrôle les plugins depuis une surface de contrôle :

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

Agrandissez l’image – vous comprendrez.

Pour les types de valeurs discrètes (par exemple, le mode Bombardier), je profite du fait que les 32 VPots (encodeurs rotatifs) de la surface ont également un comportement de commutateur – vous appuyez sur le dessus du VPot – c’est un momentané à membrane typique.

J’utilise ensuite une table de correspondance pour parcourir les valeurs disponibles à chaque pression – c’est beaucoup plus propre et prévisible que d’utiliser l’encodeur rotatif pour définir les valeurs discrètes :

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 dans le cas du 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)

Cette approche fonctionne parfaitement sur le Bombardier, le Rocket, le 1973 et le Vibe EQ, partout sauf dans les 2 sections mentionnées ci-dessus.

J’ai obtenu les valeurs des paramètres en mettant un point d’arrêt dans le débogueur sur l’appel du SDK Reaper :

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

et j’utilise aussi :

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

Donc, par exemple sur le Vibe EQ :

Définir la valeur à 0,8333 règle l’interface graphique et le plugin sur 6,0 KHz, mais la chaîne renvoyée dans “parameterValueString” dans le code ci-dessus est toujours 3150.

Si vous augmentez ensuite à 1,0, tout (l’interface graphique, le plugin, la chaîne renvoyée) s’aligne à nouveau sur 8,0 KHz.

Toutes les autres valeurs fonctionnent parfaitement.

Le comportement du Bombardier est noté dans un message précédent.

Je suis juste curieux de savoir si c’est quelque chose que je fais de mal de mon côté.

8

Huh… si c’est juste la chaîne de paramètres formatée, alors c’est probablement dans le code IPlug plutôt que dans “mon” code… on ne définit pas explicitement les chaînes de valeur en manipulant les contrôles ; c’est un comportement hérité d’IPlug.

Re: la représentation GUI des contrôles qui ne change pas… cela devrait être le contrôle qui n’est pas marqué comme sale… ne sachant pas qu’il a besoin d’être redessiné. Je vais vérifier avec schwa et voir si c’est un défaut d’IPlug, ou (plus probablement) un défaut dans mon cerveau. :slight_smile:

Scott

9

Cool, merci d’avoir étudié la question.

Je ne suis pas familier avec le code d’IPlug et je ne savais pas où se situait la division entre celui-ci et votre code.

Il me semble étrange que cela n’apparaisse que dans ce cas précis, cela pourrait encore être quelque chose que je fais mal ici.

En ce qui concerne la représentation de l’interface graphique — oui, cela ressemble exactement à un « dirty flag » non défini, ou à un événement qui ne se déclenche pas, ce genre de choses.

10

Le code IPlug est disponible gratuitement dans le cadre des bibliothèques wdl sur le site web de Cockos, si vous souhaitez le télécharger à titre de référence. Vous pourriez faire bien pire pour un tas d’utilitaires/graphiques que d’utiliser le reste de wdl, aussi… Le contrôle qui fait les boutons de fréquence et de mode est en fait une classe que j’ai écrite (IDetentKnob) qui hérite de la classe IKnobMultiControl de la bibliothèque IPlug. IDetentKnob ne fait pas partie d’IPlug, cependant… bien que je puisse décider de la reverser au projet à un moment donné.

Scott