Bug minore di aggiornamento GUI nello switch di modalità

JRR shop sta svendendo le C4 a 400 dollari, non ho potuto resistere.

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

Sono un programmatore, quindi ho deciso di integrare la C4 con la mia MCU — ho chiesto sul forum di Reaper — zero interesse — così ho il raro lusso di programmare una soluzione personalizzata che si adatti alle mie esigenze personali.

Per questo motivo ho optato per una soluzione codificata strettamente (hard coded), che mi permette di usare gli interruttori VPot invece dei messaggi rotativi per cose come l’interruttore della modalità Bombardier, oltre ad avere il controllo completo sul layout e sul posizionamento dei parametri sulla superficie.

Posso scorrere senza problemi e il display LCD della C4 si aggiorna perfettamente (I, II, III, IV, Flat) ma l’interfaccia grafica (GUI) rimane bloccata, finché qualsiasi altro controllo (diciamo Release) non viene regolato dalla superficie di controllo, quindi l’interruttore di modalità salta nella posizione corretta.

Sembra la semplice questione di un trigger di evento GUI mancante solo su quel controllo.

Modifica: — È un po’ più complicato — salendo (cioè la superficie di controllo cambia da Modalità I a Modalità II) si comporta come sopra — scendendo è strano, sembra saltare un solo passo alla volta, anche se potrebbe essere stato spostato di 3 passi

Solo per curiosità, potresti vedere se le manopole di selezione della frequenza del VibeEQ fanno lo stesso?

Ho appena passato un’ora a programmare la mappatura VibeEQ e sembra andar bene.

In realtà sembra esserci un piccolissimo bug nella sezione Hi Mid.

Impostando il valore a 0,8333 si imposta la GUI e il plugin stesso a 6,0 KHz, ma la stringa riportata nel parametro FX è ancora 3150.

Se poi si aumenta a 1,0, tutto (la GUI, il plugin, la stringa riportata) si riallinea a 8,0 KHz.

Bump,

Qualcuno può verificare quanto ho detto, o sono di nuovo alle mie solite «trucchi da programmatore stupido», avendo perso l’ennesimo bug ovvio nel mio software? :slight_smile:

Beh, di certo PENSAVO che stesse facendo quello che doveva fare… e per quanto ne so, il codice della classe di controllo per le manopole a scatto in Vibe EQ e Bombardier è effettivamente identico… Non sono sicuro di riuscire a spiegarlo. In pratica, tiene traccia di due valori… il valore di «visualizzazione» che viene mantenuto solo finché il mouse è premuto o la rotella del mouse viene girata, e il valore del parametro, che cambia solo quando il valore di visualizzazione supera il punto intermedio tra due scatti. Una volta rilasciato il mouse, il valore di visualizzazione dovrebbe «scattare» al valore del parametro disponibile più vicino.

Quali eventi stai finendo per inviare al plugin quando giri le manopole in giro?

Scott

È più che probabile che stia facendo qualcosa di stupido io da questa parte :slight_smile:

In pratica sto controllando i plugin da una superficie di controllo:

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

aggrandisci l’immagine – ti farai un’idea.

Per i tipi di valori discreti (ad es. Bombardier Mode) sfrutto il fatto che i 32 VPot (encoder rotativi) sulla superficie hanno anche un comportamento di interruttore – si preme la parte superiore del VPot – è un tipico momentaneo a membrana.

Utilizzo quindi una tabella di ricerca per scorrere i valori disponibili ad ogni pressione – è molto più pulito e prevedibile che usare l’encoder rotativo per impostare i valori discreti:

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 nel caso dell’EQ Vibe:

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)

Questo approccio funziona perfettamente su Bombardier, Rocket, 1973 e Vibe EQ ovunque tranne le due porzioni citate sopra.

Ho ottenuto i valori dei parametri mettendo un breakpoint nel debugger sulla chiamata Reaper SDK:

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

e uso anche:

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

Quindi, ad esempio sull’EQ Vibe:

Impostando il valore a 0.8333 si impostano la GUI e il plugin stesso a 6.0KHz, ma la stringa riportata in “parameterValueString” nel codice sopra è ancora 3150.

Se poi si aumenta a 1.0, tutto (la GUI, il plugin, la stringa riportata) si allinea di nuovo a 8.0KHz.

Tutti gli altri valori funzionano perfettamente.

Il comportamento del Bombardier è stato notato in un post precedente.

Sono solo curioso di scoprire se è qualcosa che sto facendo di sbagliato da questa parte.

Uhm… se si tratta solo della stringa di parametro formattata, allora probabilmente è nel codice di IPlug piuttosto che nel “mio” codice… non si impostano esplicitamente le stringhe di valore quando si manipolano i controlli; è un comportamento ereditato da IPlug.

Riguardo alla rappresentazione grafica dei controlli che non cambiano… ciò significherebbe che il controllo non viene contrassegnato come “sporco”… non sapendo che deve essere ridisegnato. Verificherò con schwa e vedrò se è un difetto di IPlug, o (più probabilmente) un difetto del mio cervello. :slight_smile:

Scott

Ottimo, grazie per averci dato un’occhiata.

Non ho familiarità con il codice di IPlug e non sapevo dove fosse la divisione tra esso e il tuo codice.

Sembra strano che si presenti solo in questo caso, potrebbe essere ancora qualcosa che sto facendo di sbagliato qui.

RE: rappresentazione GUI – sì, sembra esattamente come se un flag di modifica non fosse impostato, o un evento non si attivasse, cose del genere.

Beh, il codice IPlug è liberamente disponibile come parte delle librerie wdl sul sito web di Cockos, se vuoi prenderlo solo come riferimento. Potresti fare molto di peggio per un sacco di utilità/grafica che usare il resto di wdl, anche… Il controllo che fa le manopole di frequenza e modalità è in realtà una classe che ho scritto (IDetentKnob) che eredita dalla classe IKnobMultiControl di IPlug. IDetentKnob non fa parte di IPlug, però… anche se potrei andare avanti e contribuirlo al progetto ad un certo punto.

Scott