Kleiner GUI-Update-Bug in Mode Switch

Der JRR Shop verramscht C4s für 400 $, da konnte ich nicht widerstehen.

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

Ich bin Programmierer, also beschloss ich, den C4 in mein MCU zu integrieren – fragte im Reaper-Forum – null Interesse – so habe ich den seltenen Luxus, eine Lösung maßzuschneidern, die meinen persönlichen Bedürfnissen entspricht.

Deshalb habe ich mich für eine fest codierte Lösung entschieden, die es mir ermöglicht, die VPot-Schalter anstelle der Drehknopfnachrichten für Dinge wie den Bombardier Mode-Schalter zu verwenden und gleichzeitig die volle Kontrolle über das Layout / die Parameterplatzierung auf der Oberfläche zu haben.

Ich kann problemlos durchschalten und das C4-LCD aktualisiert sich perfekt (I, II, III, IV, Flat), aber die GUI bleibt hängen, bis ein anderer Regler (sagen wir Release) von der Bedienoberfläche aus angepasst wird, dann springt der Mode-Schalter in die korrekte Position.

Scheint einfach eine fehlende GUI-Ereignisauslösung bei diesem Regler allein zu sein.

Bearbeitung: – Es ist etwas komplizierter – das Hochgehen (d.h. die Bedienoberfläche wechselt von Modus I zu Modus II) verhält sich wie oben beschrieben – das Heruntergehen ist seltsam, es scheint nur einen Schritt auf einmal zu springen, obwohl es 3 Schritte bewegt worden sein könnte

Nur aus Neugier, könntest du sehen, ob die Frequenz-Wahlschalter von VibeEQ dasselbe tun?

Ich habe gerade eine Stunde damit verbracht, das VibeEQ-Mapping zu programmieren, es scheint völlig in Ordnung zu sein.

Tatsächlich scheint es im Hi-Mid-Abschnitt einen sehr kleinen Fehler zu geben.

Das Setzen des Wertes auf 0.8333 stellt die GUI und das Plugin selbst auf 6.0KHz ein, aber der im FX-Parameter gemeldete String ist immer noch 3150.

Wenn man dann auf 1.0 erhöht, stimmen alles (die GUI, das Plugin, der gemeldete String) wieder bei 8.0KHz überein.

Schubsen,

Kann das jemand überprüfen, oder bin ich wieder einmal bei meinen üblichen „dummen Programmierertricks“ und habe einen weiteren offensichtlichen Fehler in meiner Software übersehen? :slight_smile:

Nun, ich DACHTE bestimmt, dass wir es so weit hatten, dass es das tut, was es soll … und soweit ich weiß, ist der Code der Steuerklasse für die Rastknöpfe in Vibe EQ und Bombardier praktisch identisch … ich bin mir nicht sicher, ob ich es erklären kann. Es verfolgt im Grunde zwei Werte … den „Anzeigewert“, der nur gehalten wird, während die Maustaste gedrückt ist oder das Mausrad gedreht wird, und den Parameterwert, der sich nur ändert, wenn der Anzeigewert den halben Punkt zwischen zwei Rasten überschreitet. Sobald Sie die Maustaste loslassen, sollte der Anzeigewert auf den nächstgelegenen verfügbaren Parameterwert „springen“.

Welche Ereignisse senden Sie an das Plugin, wenn Sie die Knöpfe drehen?

Scott

Es ist mehr als wahrscheinlich etwas Dummes, das ich hier mache :slight_smile:

Grundsätzlich steuere ich die Plugins von einer Bedienoberfläche aus:

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

Erweitere das Bild – dann verstehst du es.

Für die diskreten Wertetypen (z. B. Bombardier-Modus) nutze ich die Tatsache, dass die 32 VPots (Drehgeber) auf der Oberfläche auch über Schaltfunktionen verfügen – man drückt die VPot-Oberseite hinunter – es ist ein typischer Membran-Taster.

Dann verwende ich eine Tabellensuche, um bei jedem Drücken die verfügbaren Werte zu durchlaufen – das ist viel sauberer und vorhersehbarer, als den Drehgeber zum Einstellen der diskreten Werte zu verwenden:

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)

oder im Fall des 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)

Dieser Ansatz funktioniert perfekt beim Bombardier, Rocket, 1973 und Vibe EQ überall, außer in den beiden oben genannten Abschnitten.

Ich habe die Parameterwerte erhalten, indem ich den Debugger beim Reaper SDK-Aufruf als Haltepunkt verwendet habe:

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

und ich verwende auch:

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

Wenn ich beispielsweise beim Vibe EQ:

den Wert auf 0.8333 einstelle, werden die GUI und das Plugin selbst auf 6.0KHz gesetzt, aber der in „parameterValueString“ im obigen Code gemeldete String ist immer noch 3150.

Wenn man ihn dann auf 1.0 erhöht, stimmen alles (die GUI, das Plugin, der gemeldete String) wieder bei 8.0KHz überein.

Alle anderen Werte funktionieren perfekt.

Das Verhalten des Bombardier wird in einem früheren Beitrag beschrieben.

Ich frage mich einfach, ob ich hier etwas falsch mache.

Huh…wenn es nur der formatierte Parameter-String ist, dann liegt das wahrscheinlich am IPlug-Code und nicht an “meinem” Code…man setzt die Wert-Strings nicht explizit, wenn man die Steuerelemente manipuliert; das ist ein geerbtes Verhalten von IPlug.

Bzgl. der GUI-Darstellung von Steuerelementen, die sich nicht ändert…das müsste ziemlich sicher daran liegen, dass das Steuerelement nicht als “dirty” markiert wird…und nicht weiß, dass es neu gezeichnet werden muss. Ich werde mich mit schwa in Verbindung setzen und sehen, ob das ein Defekt in IPlug ist, oder (wahrscheinlicher) ein Defekt in meinem Kopf. :slight_smile:

Scott

Cool, danke, dass du dir das angesehen hast.

Ich bin mit dem IPlug-Code nicht vertraut und wusste nicht, wo die Trennung zwischen ihm und deinem Code lag.

Es scheint merkwürdig, dass es nur in diesem einen Fall auftaucht, könnte immer noch etwas sein, das ich hier falsch mache.

RE: GUI-Darstellung – ja, es fühlt sich genau so an, als ob ein „Dirty-Flag“ nicht gesetzt wird oder ein Ereignis nicht ausgelöst wird, so etwas in der Art.

Nun, der IPlug-Code ist kostenlos als Teil der WDL-Bibliotheken auf der Cockos-Website verfügbar, falls Sie ihn nur als Referenz herunterladen möchten. Für eine Reihe von Dienstprogrammen/Grafiken könnten Sie auch schlechtere Dinge tun, als den Rest von WDL zu verwenden … Die Steuerung für die Frequenz- und Modusknöpfe ist tatsächlich eine Klasse, die ich geschrieben habe (IDetentKnob), die von der Standard-IPlug-Klasse IKnobMultiControl erbt. IDetentKnob ist jedoch nicht Teil von IPlug … obwohl ich vielleicht irgendwann beschließe, es dem Projekt wieder zur Verfügung zu stellen.

Scott