Synthé additif ...

Salut,


Je bosse actuellement sur un module d'oscillateurs.

Pour l'instant je suis au stade expérimental.

Bientôt il faudra que je me décide pour déterminer les paramètres accessibles à l'utilisateur.

La synthèse additive permet de contrôler précisement le contenu harmonique d'une onde, contrairement au dessin de la forme qui crée un contenu arbitraire, souvent pas très musical.

Est-ce qu'un synthé hybride (additif/soustractif) vous permettant de créer vos propres formes d'onde vous intéresse ?

Il y aura une section de formes standards et une autre pour la création.

Ou bien préférez-vous des formes déjà crées ?


Xavier

Bonjour,
grand amateur du KX-Omni, bien que je ne l'aie pas encore utilisé à loisir (l'achat du Z3TA m'en a quelque peu éloigné), j'attends ce vsti avec impatience.
Peut-être que des formes d'ondes déjà créées seraient utiles, mais rien n'empêche d'y ajouter des sections à créer soi-même.
Bref, je suis à fond pour ce plug à synthèse additif !!

Evidemment je suis plus pour l'additive.
Sine, Saw, Pink et Square feraient l'affaire.

Tout dépend aussi de la qualité de la synthès des filtres et du reste.

Allez une petite variable aléatoire pour faire plus réaliste. Tu sais les sythés qui dérivent tant en hauteur que par la phase. C'est ça qui donne le son!

Je me suis mal exprimé ; comme Ehma, je suis plus pour l'additive (c'est un peu moins répandu que l'analogique soustractive).

Salut,


Je me permets de vous poser une autre question.

Les formes sont automatiquement enregistrées sur le disque dur.

Suivant la qualité souhaitée le calcul peut varier d'une dizaine de secondes à une minute :

calcul sur 32 bits (Float)
de 20 à 120 tables par forme d'onde.
de 512 à 4096 samples par table.

Le nombre d'harmoniques est calculé en fonction de la fréquence maximun de l'oscillo (21000hz) :
1530 pour 13.75 hz (0 volts) à 1 pour 14080 hz (10 volts)
calcul du gibbs (lissage de la forme)
etc...

Laisser le choix du nombre de tables et de samples à l'utilisateur me complique la vie, car dans mon module d'oscillateurs j'utilise deux oscillateurs indépendants lisant deux formes d'ondes chacun , soit en tout 4 formes d'ondes en même temps.

Si je laisse le choix de la qualité à l'utilisateur, je suis obliqé de faire deux processus de lecture par oscillos alors que si les formes d'ondes ont toutes les mêmes caractéristiques (pas de choix par l'utilisateur) je peux utiliser un seul processus.

Afin d'économiser du CPU, je ne fais pas d'interpolation entre les tables, donc pour avoir le meilleur rendu dans les hautes fréquences (>16000hz) il est préférable d'utiliser le maximum de tables.

Donc voici ma question par rapport au temps de calcul de la forme d'onde :

Préférez vous attendre et avoir la meilleure qualité ou bien êtes-vous pressés ?


Xavier

Bon, c'est un peu trop technique pour moi, là, mais je vais faire preuve de maturité, pour une fois : personnellement, je ne suis pas pressé.

Là je ne comprends pas.

Pourquoi veux tu créer des tables d'ondes sur disque.
Surtout si 80% ne seront jamais utilisées.

As tu des notions de Thread ?
Car c'est dans les "OnIdle" que tu dois inclure ta boucle de création et ce en fonction de la taille des buffers demandée par l'application.

Au niveau des sinusoïde il y a une méthode pour convertir des Sin en addition, ce qui fait gagner en CPU. Je ne m'en souviens plus, mais ça doit éxister sur le web.

Heuuu... moi je retourne à mes casseroles c'est un peu trop technique là...

Salut,

Ehma a écrit:
Pourquoi veux tu créer des tables d'ondes sur disque.
Surtout si 80% ne seront jamais utilisées.

Oui, cela est vrai dans les notes graves et surtout avec les notes aigues mais je modifierai ma procédure de choix des tables d'onde plus tard.

En fait je veux éviter un calcul de l'onde au lancement du plugin, en admettant que j'opte pour la qualité la plus haute, cela fait 120*4096*(1530 à 1) calcul de données sur 32 bit, je pourrais les intégrer
dans mon module (genre wave-tbl[0]=1.220 etc..) , cela est trop fastidieux.
Pour l'écriture et la lecture des données j'utilise en gros cela :
File*Wavdata(filename,"rb");
fread(&wav_tbl,sizeof(float), table_size*ntbl, Wavdata);
close(Wavdata);

Cela est rapide et consomme peu de ressources.

J'utilise la fonction CreateSharedLookupTable pour que la lookuptable soit commune à tous les modules utilisés par le plugin.

En fait je ne sais pas si avec la SDK de SE on peut sauvegarder des valeurs précalculées, je poserai la question à Jeff.

As tu des notions de Thread ?
Car c'est dans les "OnIdle" que tu dois inclure ta boucle de création et ce en fonction de la taille des buffers demandée par l'application.

euh... non, il y a peut être des limites avec la SDK de SE, j'essayerai de me débrouiller avec. L'idéal serait que l'onde se cacule en tâche de fond.
Mais je crois que cela dépasse mes compétences actuelles.
Je me renseignerai sur le forum de la SDK de SE.

Au niveau des sinusoïde il y a une méthode pour convertir des Sin en addition, ce qui fait gagner en CPU. Je ne m'en souviens plus, mais ça doit éxister sur le web.

Peut être mais dans la mesure où le calcul est nécessaire, je préfère utiliser les fonctions mathématiques cosf(),sinf(), powf().

Je vais créer un module de création de forme d'onde, l'utilisateur pourra créer ses formes en dehors de sa session et le module d'oscillos se contentera de lire les données enregistrées dans le répertoire de la session.
Le calcul consomme trop de ressource pour être fait pendant une session dans cubase (50% de CPU avec un p4 3g hz)
Je suis en train de tester cela en ce moment.

Au début de l'été je ferai un petit plugin de test,
et en fonction des retours je terminerai la version bêta en septembre.

Merci Ehma .

a+

Xavier

Et dire que tout ça finit par faire du son !

Merci pour cette intervention.

Je vous en prie... De rien...
Si vous en voulez d'autres, tout aussi utiles, y a qu'à demander...

Mais faut pas que ça empêche Xavier et Ehma de continuer. J'adore les langues étrangères...

Salut,


Excusez moi pour ces posts techniques, mais cela me permet mieux visualiser mes problèmes et de faire des choix.

Sinon la lecture des fichiers passe comme une lettre à la poste (<1% de CPU ) dans cubase et le calcul même s'il fait glisser le buffer asio (dans le cas d'un calcul et d'une lecture audio simultanés), ne fait pas planter cubase et reste stationnaire à 50% de CPU.

Je crois qu'il y a une solution avec les modules utilisant une GUI.

Pour le temps de calcul je vais intrégrer un mode "Preview", l'utilisateur calculera l'onde en basse résolution (<1 seconde d'attente).

a+

Xavier

Excusez moi pour ces posts techniques, mais cela me permet mieux visualiser mes problèmes et de faire des choix

Non tu n'as pas à t'excuser !

Comme on est un peu à côté de la plaque niveau technique on ne peut que dire des conneries... c'est juste pour dire qu'on vous lit mais comme on peut pas se permettre de vous répondre en rentrant dans le technique on fait dans le léger...
Mais vous pouvez continuer, c'est intéressant !

Salut,

Oui, j'avais bien compris, le fait de discuter sur mes projets m'aide à continuer, plus je programme, plus j'ai des idées de modules etc...
Vos avis, même s'ils ne sont pas très techniques peuvent m'aider à faire des choix.
Je suis au stade des essais et si vous m'indiquez par exemple que cela ne vous dérange pas d'attendre un calcul, cela m'aide beaucoup.
Avec le KXomni j'avais pris des décisions sans trop me préoccuper de l'avis des éventuels utilisateurs, résultat je l'ai diffusé trop tôt.
De plus il est toujours souhaitable d'avoir des avis de musiciens car le but d'un bon vsti est quand même de se faire plaisir d'un point de vue musical.

a+

Xavier

Ben moi, je ne suis pas musicien, mais ça ne m'empêche pas de me sentir plein de reconnaissance pour ceux qui passent du temps à développer un vsti qu'ils diffusent ensuite gratuitement.
Alors merci Xavier.

de 20 à 120 tables par forme d'onde.
de 512 à 4096 samples par table.

quelqu'un peut m'expliquer ce qu'est cette histoire de "tables par forme d'onde? je pige pas..."

De quelle manière pourra t-on créer des ondes avec ce module, quelle démarche devra faire concrètement l'utilisateur du plug? (puisqu'ils ne les dessinent pas si j'ai bien suivi...)

Préférez vous attendre et avoir la meilleure qualité ou bien êtes-vous pressés ?

comment se manifestera cette perte de qualité?

tant qu'on y est, si quelqu'un pouvait m'éclaircir les "samples"? je connais pas, j'imagine ça comme une unité minimal de temps de calcul, mais en fait je sais pas ce que c'est...

après ces réponses, j'essaierais d'émettre un avis

Salut Nyl,

théorie de Fourier:

Une onde périodique comme une "Saw" est composée d'un nombre infini d'harmoniques élémentaires (ondes sinusoïdales) dont le niveau et la fréquence sont des multiples de la note fondamentale.

Le problème est que l'infini ne peut pas exister avec le numérique.
On est obligé de limiter la bande passante sinon l'aliasing apparait autour des fréquences de +de 20000 hz.

Avec le système additif on recompose l'onde en additionnant les harmoniques.
On modifie le niveau avec une fonction nommée gibbs pour atténuer les petites oscillations des hautes fréquences crées parce que le nombre d'harmoniques n'est pas infini (lissage de la forme).

Le nombres d'harmoniques est différent suivant la hauteur de la note.

pour 0 volt on a une fréquence de 13.75 hz
21000 hz/13.75=1530 harmoniques
pour 10 volt >14080hz
21000 hz/14080=1 harmonique

Il faut donc créer plusieurs "tables d'onde", 120 notes midi =120 tables d'onde .

Ces tables sont en général crées à partir de 512 samples voir +, 4096 samples.
Quand je parle de calcul, il s'agit de calculer la valeur de chaque samples composant cette table.

a+

Xavier

ok, merci, je commence à comprendre; excepté pour les "samples", quelqu'un pourrait faire un peu de pédagogie pour moi là dessus s'il vous plait?
parce que je bloque du coup là.

Re

C'est de ma faute , je devrais dire "points" ou "données" ou "valeurs".

Chaque données est une valeur binaire de 32 bits.

a+

Xavier

est ce que ça correspond à l'échantillonnage, le nombre de "tranches" par seconde de valeurs échelonnées sur 32 bits ?

si c'est pas ça, que change concrètement le nombre de samples sur la formation du son (je suis chiant hein?). Je suppose que plus il y en a, meilleure est la définition du son?

Peut être que si Ehma passe par là, il pourra m'éclairer; sinon je vais tacher de me renseigner sur le web...

(Sinon tu m'as bien motivé pour le c++, je viens d'acheter "le c++ pour les gros nuls", histoire d'avoir quelques bases avant de m'occuper du SDK.)

Salut,

Oh là, tu te compliques la vie, il s'agit d'une table contenant, par exemple, 4096 valeurs codées sur 32 bits, exactement comme une piste audio sauf que le processus de lecture de l'oscillateur va lire cycliquement ces valeurs.
Si la valeur nécessaire à la fabrication du signal est entre deux échantillons, il y aura une interpolation de cette valeur.

Pour la perte de qualité, il s'agit d'un bruit de fond numérique, on ne l'entend pas, cela est très faible. Et dans le cas d'une utilisation de l'oscillateur en Lfo, le signal est moins précis.

Vas-y mollo avec le c++, c'est très décourageant au début, il faut avoir un projet de module bien ciblé.
C'est le besoin de mon module Kxmod qui m'a poussé à me lancer là dedans.


a+

Xavier