Dan ton patch, il faut que tu lisses la transition entre le domaine "contrôle" et "audio". Quand tu redimensionnes, tu envoies des valeurs toutes les 20ms et il y a une grosse différence à chaque fois.

Pour lisser il faut insérer ce qui suit avant les entrées droites des [*~] (en bas du patch) là où tu injectes les bornes du tronçon à lire :

|
[$1 20(
|
[line~]
|

C'est le moyen le plus simple de convertir une valeur de contrôle en valeur audio sans faire de clic.

Les flux de contrôle sont cadencés à 20ms dans Pd.
Donc si tu as un une série de valeurs qui arrive à cette vitesse, c'est plus lisse de donner cette même durée comme temps à ton lissage, mais ça n'est pas obligé.


Si tu utilises un [speedlim 100] alors pourquoi pas faire un lissage sur 100ms.

http://fr.flossmanuals.net/puredata/ch0 … io-dans-pd

citation :

Cadence des objets audio~ et contrôle

Les objets audio et les objets de contrôle ne fonctionnent pas à la même cadence. Les objets audio fonctionnent en continu (stream) à la cadence spécifiée dans les configurations audio (Audio Settings) ; quant aux objets de contrôle, ils fonctionnent beaucoup plus lentement. Ces différences de cadence peuvent générer des artefacts audio, des « clics », qu'il est préférable d'éviter. On peut donc contrôler les objets audio comme [*~] avec des signaux audio générés avec [line~] plutôt qu'avec des boîtes de message.

pob a écrit:

Les flux de contrôle sont cadencés à 20ms dans Pd.

Bein ça m'étonne drôlement !  J'ai toujours cru que les objets de contrôle étaient cadencés à chaque "rafraîchissement" de bloc, soit généralement 64 valeurs soit ~0.00145 s à 44.1 khz (c'est déjà 64x plus lent que l'audio).


Nau