Description

Opcode du greffon cuda. Ce greffon se trouve dans le répertoire des greffons et il doit être installé séparément. Le répertoire des greffons est ici : https://github.com/csound/plugins

Génère un fsig à partir d'une source audio mono, en utilisant l'analyse par recouvrement-addition d'un vocodeur de phase et un GPU.

Syntaxe

fsig cudanal ain, ifftsize, ioverlap, iwinsize, iwintype [, iformat] [, iinit]

Initialisation

ifftsize -- La taille de la TFR en échantillons. Ne doit pas forcément être une puissance de deux (bien que celles-ci sont particulièrement efficaces), mais doit être paire. Les nombres impairs sont arrondis en interne. ifftsize détermine le nombre de bins d'analyse dans fsig, soit ifftsize/2 + 1. Par exemple, si ifftsize = 1024, fsig contiendra 513 bins d'analyse, ordonnés linéairement de la fréquence fondamentale à la fréquence de Nyquist. La fréquence fondamentale de l'analyse (qui donne en principe la fréquence résoluble la plus basse) est déterminée par sr/ifftsize. Ainsi, pour l'exemple précédent en supposant que sr = 44100, la fréquence fondamentale de l'analyse vaut 43.07Hz. En pratique, comme le vocodeur de phase préserve la phase, la fréquence de chaque bin peut dévier de façon bilatérale, si bien que des composantes continues sont enregistrées. Avec un signal fortement tonal, les fréquences des bins adjacents peuvent s'aggréger très étroitement autour des partiels de la source, et les bins inférieurs peuvent même avoir des fréquences négatives.

En principe, la seule raison d'utiliser pour ifftsize une valeur qui n'est pas une puissance de deux est de s'adapter à la fréquence fondamentale connue d'une source fortement tonale. Les valeurs décomposables en plusieurs petits facteurs peuvent être presqu'aussi efficaces que les tailles en puissance de deux ; par exemple : 384, pour une source dont la hauteur est proche du la grave à 110 Hz.

ioverlap -- La distance en échantillons (« taille du saut ») entre les trames d'analyse se recouvrant. En principe, doit valoir au moins ifftsize/4, par exemple 256 dans l'exemple ci-dessus. ioverlap determine le taux d'analyse sous-jacent, soit sr/ioverlap. Il n'est pas nécessaire que ioverlap soit un facteur simple de ifftsize ; par exemple, une valeur de 160 sera légale. Le choix de ioverlap peut être dicté par l'importance de la modification de hauteur appliquée au fsig, s'il y en a une. En règle générale, plus la transposition est importante et plus le taux d'analyse doit être élevé, ce qui implique une plus petite valeur de ioverlap. Un taux d'analyse plus élevé peut aussi être plus avantageux avec des sons à transitoires à large bande tels que des tambours (pour lesquels une petite fenêtre d'analyse diminue l'étalement mais augmente le nombre d'erreurs relatives à la fréquence).

Noter qu'il est possible, et raisonnable, d'avoir différents fsigs dans un orchestre (même dans le même instrument), évoluant à différents taux d'analyse. Les interactions entre de tels fsigs ne sont pas couramment supportées et l'opcode d'affectation de fsig ne permet pas la copie entre fsigs ayant des propriétés différentes, même si la seule différence est la valeur de ioverlap. Cependant, ceci ne conduit pas à une impasse, car il est théoriquement possible d'effectuer une conversion grossière du taux (en particulier par rapport aux fichiers d'analyse en mémoire) comme on le fait dans les techniques du domaine temporel.

iwinsize -- la taille en échantillons du filtre de la fenêtre d'analyse (fixé par iwintype). Doit valoir au moins ifftsize, et peut être utilement plus grande. Bien que d'autres proportions soit permises, il est recommandé que iwinsize soit toujours un multiple entier de ifftsize, par exemple 2048 dans l'exemple ci-dessus. En interne, la fenêtre d'analyse (Hamming, von Hann) est multipliée par une fonction sinc afin que les amplitudes soient nulles aux frontières de trame. La plus grande taille de fenêtre d'analyse s'est révélée particulièrement importante pour la resynthèse par banc d'oscillateurs (par exemple en utilisant pvsadsyn), car elle a pour effet d'augmenter la résolution en fréquence de l'analyse et ainsi, la précision de la resynthèse. Comme noté ci-dessus, iwinsize détermine la latence globale du système d'analyse/resynthèse. Dans bien des cas, et particulièrement en absence de transposition, on constate que l'égalité iwinsize=ifftsize fonctionne très bien et offre la latence la plus faible.

iwintype -- La forme de la fenêtre d'analyse. Actuellement, seulement deux choix sont implémentés :

Les deux sont aussi supportées par le format de fichier PVOC-EX. Le type de fenêtre est stocké comme attribut interne du fsig, avec les autres paramètres (voir pvsinfo). D'autres types pourront être implémentés dans le futur (par exemple la fenêtre de Kaiser, aussi supportée par PVOC-EX), bien qu'une alternative évidente soit de permettre la définition des fenêtres via une table de fonction. Le problème ici est la contrainte de taille en puissance de deux des tables de fonction, ce qui en fait une solution incomplète. La plupart des utilisateurs jugeront que la fenêtre de Hamming est suffisante pour les besoins courants et peut être le choix par défaut.

iformat -- (facultatif) Le format d'analyse. Pour le moment un seul format est implémenté par cet opcode :

C'est le format classique du vocodeur de phase ; facile à traiter, et naturel pour la resynthèse par banc d'oscillateurs. Il serait très facile (on pourrait dire tentant) de ne pas traiter une trame de fsig purement comme une trame de vocodeur de phase mais comme une trame de synthèse additive générique. Il est en fait possible d'utiliser un fsig de cette manière, mais il est important de garder à l'esprit que les deux ne sont pas, à strictement parler, directement équivalents.

D'autres formats importants (supportés par PVOC-EX) sont :

iformat est là au cas où il pourrait être utile par la suite de supporter ces autres formats. Les formats 0 et 1 sont en relation étroite (car la phase est « cyclique » dans les deux cas - il est trivial de convertir de l'un à l'autre), alors que le format complexe pourrait garantir un second type explicite de signal (un « csig ») spécialement pour les traitements à base de convolution, et d'autres traitements dans lesquels le complément des opérateurs arithmétiques peut être utile.

iinit -- (facultatif) Ignore la réinitialisation. N'est actuellement implémenté dans aucun de ces opcodes, et il reste à décider s'il serait de quelque utilité.

	Avertissement
	Il est dangereux d'utiliser la même variable-f à la fois comme entrée et comme sortie des opcodes cuda. Ceci peut produire un comportement indéfini de certains de ces opcodes. Utilisez une variable différente à gauche et à droite de l'opcode.

Exemples

Voici un exemple de l'opcode cudanal. Il utilise le fichier cudanal.csd.

<CsoundSynthesizer>
<CsOptions>
; Select audio/midi flags here according to platform
-odac      ;;;realtime audio out
;-iadc    ;;;uncomment -iadc if realtime audio input is needed too
; For Non-realtime ouput leave only the line below:
; -o cudanal.wav -W ;;; for file output any platform
</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 2
0dbfs = 1

instr 1	;cudanal has no influence when there is no transformation of original sound

ifftsize  = p4
ioverlap  = ifftsize / 4
iwinsize  = ifftsize
iwinshape = 1							;von-Hann window
Sfile     = "fox.wav"
ain       soundin Sfile
fftin     cudanal ain, ifftsize, ioverlap, iwinsize, iwinshape	;fft-analysis of the audio-signal
fftblur   pvscale fftin, p5					;scale
aout      cudasynth fftblur					;resynthesis
          outs	  aout, aout
endin

</CsInstruments>
<CsScore>
s
i 1 0 3 512 1		;original sound - ifftsize of pvsanal does not have any influence
i 1 3 3 1024 1		;even with different
i 1 6 3 2048 1		;settings

s
i 1 0 3 512 1.5		;but transformation - here a fifth higher
i 1 3 3 1024 1.5	;but with different settings
i 1 6 3 2048 1.5	;for ifftsize of pvsanal

e
</CsScore>
</CsoundSynthesizer>

Crédits

Nouveau dans la version 6.02