comment faire des changements de paramètres en échelon dans DP?

[vberthiaume]

voir discussion dans #80

[vberthiaume]

Nous allons avoir besoin de ce feature pour faire fonctionner correctement les automations de contraintes de mouvement. À moins qu'il existe un mode d'écriture d'automation qui ne fait pas d'interpolation entre les valeurs? Reaper, par exemple, a le bon comportement: on a des changements de valeurs seulement lorsqu'on sélectionne un nouveau mode, et ensuite on a un plateau jusqu'au prochain changement de contrainte.

[vberthiaume]

ce problème est réglé à l'interne--on considère seulement les valeurs d'automation directement sur les modes de mouvement. Mais pour l'usager on ne voit pas de paliers

[vberthiaume]

Je retire mes paroles, le problème est toujours là. Si j'écris une automation qui passe directement de indépendant à circular fully fixed, on écrit ceci:

À la lecture par contre, on passe progressivement de indépendant à circular à circular fixed radius à circular fixed angle pour finalement arriver à circular fully fixed. Donc pour que l'automation des mouvement (#80) fonctionne dans DP, il va vraiment falloir implémenter les paramètres par paliers, ce qui n'est pas trivial parce que je vais devoir bypasser du code JUCE.

[Normandeau]

L'automation des Movements ne s'écrit pas dans DP 9.02 ni DP 9.12. Elle est lue par contre si on l'écrit à la main. Elle fonctionne correctement dans Logic et Reaper.

[vberthiaume]

Voici ma correspondance avec Emmanuel des GRM tools:

Bonjour Mr. Favreau,

Je travaille avec Robert Normandeau sur les plugins de la faculté de musique de l'université de Montréal (Octogris, ZirkOSC, etc). J'ai une question JUCE pour vous :).

Robert a récemment porté à mon attention que lorsque vos plugins utilisent des paramètres dont les valeurs sont des entiers, par exemple "bands" dans GRM Evoltuion, les automations de ces paramètres sont encodés par les séquenceurs en tant que changements par échelons de valeurs entières (ici, automation de bands dans GRM Evolution, roulant dans DP):

Par défaut, les paramètres des plugins JUCE (et je suspecte, tous les paramètres VST, AU, AAX, etc) sont encodés par des floats entre [0, 1], et de ce fait, je ne suis pas capable de reproduire le comportement ci-haut.

J'ai tenté de redéfinir la méthode AudioProcessor::getParameterNumSteps() dans mon code, pour spécifier les échelons que je voulais, mais il ne semble pas que cette méthode soit appelée par DP. J'ai également tenté d'utiliser la relativement nouvelle classe AudioParameter, genre de créer mes paramètres avec

addParameter (gain = new AudioParameterInt("gain", "Gain", 0, 5, 2));

mais hélas, cela ne produit pas les petits échelons. Avez-vous utilisé JUCE pour produire ce résultat?

Merci beaucoup et bonne journée!

===================

Bonjour Vincent,

Effectivement, le wrapper AudioUnit de Juce ne prend pas en compte les paramètres à valeurs discrètes. Vous devez modifier

ComponentResult GetParameterInfo (AudioUnitScope inScope,
AudioUnitParameterID inParameterID,
AudioUnitParameterInfo& outParameterInfo) override

En ajoutant quelque chose du genre :

if(juceFilter->getControlType(index) == kJUCE_DiscreteValues) {
int numSteps = juceFilter->getNumSteps(index);
outParameterInfo.unit = kAudioUnitParameterUnit_Indexed;
outParameterInfo.minValue = 0.0f;
outParameterInfo.maxValue = 1.0f*(numSteps-1);
}

Recherchez dans les documentations AU toutes les infos liées à kAudioUnitParameterUnit_Indexed Les valeurs de ce type de paramètres ne sont plus (du coté AU) entre 0 et 1, mais entre 0 et numSteps-1 Il faut donc aussi modifier toutes les fonctions d’accès aux paramètres :

GetParameterValueStrings
GetParameter
SetParameter
GetProperty

pour faire les conversions nécessaires.

J’espère que cela vous aidera

Bonne journée

Emmanuel Emmanuel Favreau Ina GRM | www.inagrm.com 19 Avenue du Général Mangin 75016 Paris

[Normandeau]

Copié de 135: Reaper On peut écrire et lire les Movements. Mais:

La valeur maximale (1.0) ne correspond à rien, puisque DeltaLock correspond à 0.71, donc le menu dans SpatGRIS s'affiche vide au-delà. Est-ce volontaire? Un nouveau mode en gestion?
Ah je viens de comprendre, j'étais en mode 8X8 où Symmetric X et Y n'existent pas. Les remplacer par quelque chose?
L'ordre des automation de 0.0 à 1.0 est l'inverse de l'ordre d'affichage dans SpatGRIS: de Independant (0.0) alors qu'il en haut de la liste, à DeltaLock (0.71) alors qu'il est en bas. Est-ce une fatalité?
L'automation de Movements ne fonctionne qu'en mode Write ou Latch, pas en mode Touch. Dans celui-ci, le mode choisi au départ ne peut pas être changé. Lorsqu'on en choisit un autre, cela génère une courte impulsion d'automation, mais la valeur revient toujours à la valeur de départ.
Après avoir enregistré Movements, je repasse en mode Touch pour écrire des automations de la Source 1. Le paramètre Movements est automatiquement effacé en même temps! Même chose en Latch.

Logic On ne peut pas écrire les Movements en temps réel, quelque soit le mode choisi (Write, Touch ou Latch). On peut par contre l'écrire à la main (si on connait les valeurs...) et SpatGRIS les lit.

DP Même commentaire pour DP.