Recherche de bibliothèque audio

[vohufr]

Bonsoir,

Je cherche une bibliothèque audio pour un simulateur d'orgue.

Cette bibliothèque audio, doit permettre de jouer 300 échantillons en même temps...
Je sais ! c'est énorme, mais je vois pas comment il pourrait être autrement.

45 jeux x 10 notes (ce qui est une moyenne) on atteint déjà les 450 !


je crois que SDL_* sont exclues d'avance (16 canaux max !)

Qu'en est il de openAL ? Allegro ?

Y a t'il autre chose de disponible ?


Merci d'avance

[_-Slash-_]

Pour ce type de projet tu peux soit voir OpenAL, soit FMOD.

[vohufr]

Merci J'ai commencé hier mes recherches sur openAL justement :p

Par contre, je ne trouve pas de doc C (que C++)

Tu as un lien ou quelque chose qui permette de faire quelques tests rapides en C ?

[LittleWhite]

Bonjour,

La documentation est ici : http://connect.creativelabs.com/open.../AllItems.aspx

[vohufr]

merci

[Obsidian]

Je vais peut-être dire une ânerie mais dans quel cas pourrait-on avoir besoin de jouer 300 échantillons simultanément pour simuler un orgue et comment cela peut-il produire quelque chose d'audible ?

Dans le cas extrême ou l'on jouerait une partition à 4 mains et 4 pieds, que tous les doigts seraient en pression et que certains actionneraient même deux touches consécutives à chaque fois, on atteindrait difficilement 30 échantillons simultanés.

En outre, si c'est vraiment nécessaire, tu pourrais peut-être produire des échantillons reproduisant des accords. Ça te permettrait d'économiser des canaux et, dans certains cas, d'avoir un rendu meilleur qu'avec une synthèse surchargée.

[vohufr]

car un orgue assez complet pour permettre le jeu de plusieurs estétiques de musique, possède minimum une 40ène de registres (sons différents). (L'orgue complet Romantique se compose en général entre 42 à 45 registres sur des claviers de 54 à 60 notes)

S'amuser à enregistrer des combinaisons pré-définies d'accords, ou de différents registres accouplés, augmenterait de façon exponentielle la taille de la banque son. qui doit (évidement) être totalement chargée en RAM. Car il est impensable d'imaginer charger depuis le disque dur les échantillons au moment ou on en a besoin (même avec un SSD)
(il ne s'agit pas de jouer des fichier MIDI, mais de jouer en live)

Donc, si je joue avec 8 doigts, 2 pieds (ce qui est fréquent) sur 40 registres ? (sans tenir compte que l'attaque de la note, sa tenue, et sa résolution sont dans des fichiers différents)
j'ai déjà 10 x 40 échantillons à jouer en même temps.
Imaginons maintenant le cas d'une partition comme dans la 3ème pièce de l’ascension de Messiaen ou le final de la Nativité.Ou des grandes pièces symphoniques romantiques, dans lesquelles on peut trouver 4 de ces accords par seconde sur le tutti de l'instrument sur 40 registres et bien plus sur de gros instruments...
Et bien, il devient aussi impensable de pré-enregistrer ces échantillons assemblés.
D'ailleurs, même si on voulait le faire, lesquels on choisirait ? Selon l’esthétique ou période de la musique jouée on fait des choses totalement différentes. Et c'est exactement la même réponse pour l'enregistrements d'accords pré-assemblés. les quels choisir ?

Si je joue du baroque : je prévilégie les accords majeurs mineurs ? à 2 sons ? 3 sons ? Dans quel renversement ? sur quelle octave ? et sur quel registres ?
Bach écrivait d'une façon, et Buxtehude d'une autre..
Si je joue du contemporain : c'est les mêmes questions, mais sur des règles d'écritures totalement différentes et dans une diversité encore plus étendue.

Donc la réponse est : qu'il est impossible de définir des choses simples qui reviennent souvent dans ce contexte.

Il est certain que cette appli (comme celles qui existent déjà voir : hautpwerk) nécéssitent autre chose qu'un petit P4 et 2Go de RAM. un I5 ave 8Go de RAM sont le minimum. Et un SSD pour le chargement de la banque son n'est pas un luxe, si on ne veut pas attendre 10 minutes avant de pouvoir jouer.


Voilà


Je suis disposé à répondre à ce genre de questions, par contre, je ne rentrerais pas dans ce débat : ne pas charger intégralement la banque son en RAM

Merci

[Obsidian]

Envoyé par vohufr

car un orgue assez complet pour permettre le jeu de plusieurs estétiques de musique, possède minimum une 40ène de registres (sons différents). (L'orgue complet Romantique se compose en général entre 42 à 45 registres sur des claviers de 54 à 60 notes)

Et tu joues dans les 40 registres en même temps ? C'est une vraie question parce que je ne joue pas d'orgue…

S'amuser à enregistrer des combinaisons pré-définies d'accords, ou de différents registres accouplés, augmenterait de façon exponentielle la taille de la banque son.

Il ne s'agit pas d'échantillonner tous les accords possibles, ce serait l'extrême inverse mais de trouver un compromis entre la totalité des samples possibles et 300 canaux joués simultanément.

qui doit (évidement) être totalement chargée en RAM. Car il est impensable d'imaginer charger depuis le disque dur les échantillons au moment ou on en a besoin (même avec un SSD)(il ne s'agit pas de jouer des fichier MIDI, mais de jouer en live)

Pas forcément, non. Tu vas lourdement exploiter ta machine, donc autant tirer profit de tout ce que tu as à ta disposition. Tu peux effectivement essayer d'installer 32 Go de RAM si tu en as les moyens. Par contre, un sample, aujourd'hui, est joué relativement lentement par rapport au fonctionnement global de la machine. Tu peux donc très bien fonctionner avec un buffer de taille limitée par instrument et faire du double-buffering en chargeant la moitié d'un sample pendant que la machine est en train de jouer l'autre. Bon, je suppose que les libs style OpenAL doivent savoir gérer tout cela proprement. Mais il faut se méfier des bibliothèques supposées omnipotentes.

Donc, si je joue avec 8 doigts, 2 pieds (ce qui est fréquent) sur 40 registres ? (sans tenir compte que l'attaque de la note, sa tenue, et sa résolution sont dans des fichiers différents) […] Et c'est exactement la même réponse pour l'enregistrements d'accords pré-assemblés. les quels choisir ?

Ah ben c'est toute l'idée de « l'exercice » :-) C'est une chose à laquelle il faut consacrer du temps pour trouver la meilleure configuration, et je trouve que ce serait musicalement instructif. Après, tu as peut-être autre chose à faire, mais ça ne rend pas obligatoire en soi et pour autant le fait de jouer 300 samples en même temps.

Si je joue du baroque : je prévilégie les accords majeurs mineurs ? à 2 sons ? 3 sons ? Dans quel renversement ? sur quelle octave ? et sur quel registres ?
Bach écrivait d'une façon, et Buxtehude d'une autre..
Si je joue du contemporain : c'est les mêmes questions, mais sur des règles d'écritures totalement différentes et dans une diversité encore plus étendue.

Eh bien justement, tu peux faire plusieurs patterns, chacun optimisé pour un cas particulier. C'est plus facile de les stocker sur disque que de tout charger en mémoire en même temps. Mais peu importe. On s'éloigne.

Je suis disposé à répondre à ce genre de questions, par contre, je ne rentrerais pas dans ce débat : ne pas charger intégralement la banque son en RAM

Ah ben tu fais comme tu veux, hein… :-) Mais je pense que tu as posé ce principe comme axiome de départ parce que ça avait l'air évident et sans revenir dessus après mûre réflexion. La seule chose nécessaire, c'est que les sample n'aient pas de retard quand on les sollicite. Comme on l'a dit, pour ce faire, tu peux par exemple tous les charger en mémoire, mais partiellement seulement.

Tout cela pour dire deux choses :

— À l'époque des *.MOD, qui fonctionnaient grosso-modo de la même façon, on n'avait que quatre canaux. Il était donc nécessaire d'apprendre dès le départ à les exploiter au maximum et pas de poser d'emblée le principe 1 canal = 1 instrument.
— J'ai peur qu'avec 300 voies mélangées, le résultat ne soit de toutes façons pas à la hauteur de ce que tu espères.

[vohufr]

oui je peux jouer les 40 en même temps, même plus si j'en dispose. Car dès le moment qu'on "accouple" plusieurs claviers, ou sur eux même sur une octave de plus ou/et de moins. on multiplie le nombre de touches enfoncées par autant de claviers qu'on dispose, et de registres... même chose pour les pieds.

toutes les autres questions : musicalement parlant, ça ne m'interesse pas. j'ai déjà fait cet "exercice" durant mes 10 ans d'études musicales jusqu'à l'obtention de mes prix.
C'est une analyse que je fais aujourd'hui à vue, lorsque je joue, c'est pour cela que je suis conscient qu'on ne peut prévoir des pattern pour celà.

C'est pour cela que je n'ai pas voulu parler de tout ça au départ, la seule chose que je voudrais : c'est une librairie qui est capable de faire ce que je cherche à faire.

Tout le reste, j'y ai longuement réfléchi depuis quelques mois déjà. Et il n'y a pas d'autre solution tant que les disques durs ne seront pas beaucoup plus rapides.

[pfeuh]

Salut,

Envoyé par vohufr

Je cherche une bibliothèque audio pour un simulateur d'orgue.

Tu parles d'un système à tirettes harmoniques, comme sur un Hammond? Dans ce cas, la limitation est simplement la puissance de calcul de la machine et non le nombre de canaux sonores. Tu devras écrire du code d'un peu plus bas niveau que ce que te proposent les librairies standards, et c'est tout.

Des softs très biens existent et même en open source. Beatrix qui est maintenant payant et sert de base à tous les softs embarqués dans les émulations Hammond hardware (Crumar Mojo, Fatar Numa etc...), bref toute la production italienne actuelle. Tu peux jeter un oeil au très regretté B4, de Native Instruments, qui est une très bonne émulation de Hammond sous Windows. Personnellement, n'ayant pas pu (ou alors j'y suis trop sensible) régler de gros problèmes de latence, j'ai opté pour un clone, le Mojo, donc hardware et soft embarqué.

Si tu parles plutôt d'orgue d'église, ce n'est pas trop ma culture, mais des softs payants très convaincants existent, c'est donc faisable aussi.

Pour ce genre de projet, depuis que la puissance de calcul le permet, on préfère largement la modélisation à l'échantillonnage.

A+

Pfeuh

[Bktero]

(il ne s'agit pas de jouer des fichier MIDI, mais de jouer en live)

Cette phrase dénote une méconnaissance de ce qu'est le MIDI

Donc, si je joue avec 8 doigts, 2 pieds (ce qui est fréquent) sur 40 registres ? (sans tenir compte que l'attaque de la note, sa tenue, et sa résolution sont dans des fichiers différents)

Qu'appelles-tu un registre dans cette phrase ?

[vohufr]

Je sais très bien ce qu'est le MIDI, je dis juste que mon appli ne servira pas à lire des fichiers MIDI... des fichiers .mid

Pour le registre, c'est toujours la même chose, ce que j'ai expliqué dans ma première phrase su l'avant dernier post.

pfeuh> je ne veux pas générer mes sons, mais jouer des échantillons wav...


Si vous lisez pas TOUT le post avant de répondre, on s'en sortira pas les gars...

[Bktero]

Un registre revient simplement à un sample en fait ?

(L'orgue complet Romantique se compose en général entre 42 à 45 registres sur des claviers de 54 à 60 notes)

Du coup, je ne comprends pas cette phrase

Je sais très bien ce qu'est le MIDI, je dis juste que mon appli ne servira pas à lire des fichiers MIDI... des fichiers .mid

Pourtant, tu peux jouer en live avec du MIDI. Un fichier .mid n'est rien qu'une séquence de commandes MIDI, obtenu grâce à un enregistrement live d'un instrument MIDI, ou généré par séquenceur MIDI.


D'ailleurs, avec quoi vas-tu contrôler ton application ?

[vohufr]

Un orgue est un instrument qui contient plusieurs sons, comme un synthétiseur, sauf que la différence, c'est qu'on peut les superposer sans limite en nombre...

Donc si mon instrument propose un violon (j 'ai autant d'échantillons violon que de touches du clavier) après je peux avoir aussi trompete, violoncelle, flute8, flute4, etc etc...

Oui, mais le MIDI dans mon appli, ne servira qu'à récupérer le signal de mes claviers. pas à lire un fichier. (Même si cette appli terminée, il sera facile d'ajouter une fonction de lecture des fichiers midi..)
J'avais fait cette précision, car un moment on voulait m'imposer de ne pas charger toute la banque son sous pretexte que je pouvais lister les échantillons utilisés dans un fichier midi et ne charger que ceux-ci..

[Bktero]

Tu veux faire un sampler MIDI logiciel en clair ?

[Obsidian]

Envoyé par vohufr

Donc si mon instrument propose un violon (j 'ai autant d'échantillons violon que de touches du clavier) après je peux avoir aussi trompete, violoncelle, flute8, flute4, etc etc...

Bon. Je suppose que c'est inutile de le préciser, mais si tu cherches une qualité audiophile, tous tes samples devront être numérisés à la même fréquence. En outre, ils devront probablement tous avoir une grande précision (peut-être supérieure à 16 bits) pour pouvoir être mélangées sans trop de perte d'information.

Enfin, de combien de voies de sorties comptes-tu disposer ? Est-ce que tout tes samples doivent être numérisés en 5.1 ? Parce que là, au bout d'un moment, même des centaines de giga-octets ne suffiront pas à tout charger…

J'ai fait une petite recherche pour voir quel est la limite maximum de sources audio prises en charge par OpenAL. Je suis tombé sur ceci :
http://stackoverflow.com/questions/2...aximum-sources soit une limite théorique de 255 sources sur une Ubuntu 10.1 avec les libs par défaut. C'est déjà honorable en soi, mais je doute que la machine tienne réellement la charge jusqu'à ce stade, surtout avec des samples de haute qualité.

Il faudra donc faire une config' sur mesure et éventuellement paralléliser deux machines : il est plus facile de propager de façon synchrone les événements du clavier entre deux machines que de faire en sorte qu'une même routine arrive à mixer 300 voies en temps réel.

À ce sujet, quel budget comptes-tu investir au maximum dans ta configuration ?

[vohufr]

Mes échantillons seront en 16 bits, et plus tard en 24. pas de 5.1. au pire, openAL permet de disposer la position du son.


Je ne paralléliserai pas 2 machines, et je ne dispose d'aucun budget. Je développe un logiciel à ce stage. Hauptwerk fonctionne sur un i5 2,2 avec 8go de ram. Mes banques sont feront max 8go (enfin un peu moins)
Sachant que ça tournait déjà très bien sur sur un XP 64bits 8go de RAM et Core2duo 1.8G.

255 sources sont théoriquement insuffisantes. si aucune librairie n'est capable de jouer plus, c'est qu'il faut que je rééchantillonne à la volée les samples avant lecture, pour les fusionner.
A ce moment là, il faudra que je me dirige vers en partie vers DSP

[Obsidian]

255 sources sont théoriquement insuffisantes. si aucune librairie n'est capable de jouer plus, c'est qu'il faut que je rééchantillonne à la volée les samples avant lecture, pour les fusionner.

Et, à ton avis, que crois-tu que font les bibliothèques en question ? Il n'y a toujours qu'une seule sortie à la fin (enfin, de une à cinq en fonction de la sonorisation choisie).

D'une part, je suis bien tenté de dire que 255 voies différentes, c'est déjà beaucoup et que si avec ça ton orgue n'est pas complet, il serait déjà bien doté et que ça vaudrait le coup de voir le résultat. Ensuite — et surtout — si OpenAL peut virtuellement jouer 255 sources différentes, il n'y a pas raison qu'il ne puisse pas aller plus loin.

Je pense qu'il n'y a rien de codé fondamentalement sur 8 bits dans OpenAL. Donc soit c'est une limite calculée à l'exécution par la bibliothèque en fonction des ressources disponibles et dans ce cas, il te suffit d'en ajouter, soit c'est une limite arbitraire posée parce qu'il faut en mettre une et, là, il te suffira d'apporter quelques modifications à la bibliothèque et de la recompiler pour aller plus loin.

A ce moment là, il faudra que je me dirige vers en partie vers DSP

À moins que tu parles d'un produit particulier, le « DSP », pour moi, c'est le traitement numérique du signal. Donc soit tu utilises une puce dédiée et il faudra nous indiquer laquelle, soit tu veux confier cette tâche au processeur et on revient au point de départ.

[vohufr]

Envoyé par Obsidian

D'une part, je suis bien tenté de dire que 255 voies différentes, c'est déjà beaucoup et que si avec ça ton orgue n'est pas complet, il serait déjà bien doté et que ça vaudrait le coup de voir le résultat.

Le musicien que je suis n'est pas du tout d'accords avec ce point de vue... tu te contenerais d'une voiture sans essuie glace ? après tout, quand il y a du soleil, ils ne sont pas utiles...

Pour le DSP, je le ferais niveau logiciel, et donc, il faudrait que je vois comment fonctionne openAL pour reproduire ce mixage moi même, afin de pouvoir obtenir mes 300 voix.

[Obsidian]

Envoyé par vohufr

Le musicien que je suis n'est pas du tout d'accords avec ce point de vue... tu te contenerais d'une voiture sans essuie glace ? après tout, quand il y a du soleil, ils ne sont pas utiles...

Ce n'est pas comparable. Il ne s'agit pas de te priver d'un des éléments essentiels mais d'utiliser une quantité moins grande de ressources du même type. Ce serait plutôt comme avoir une voiture qui roule à 130 au lieu de 150 : je n'ai pas dit que tu devais t'en contenter si ce n'est pas ton choix, mais je dis que tu peux déjà largement rouler avec.

Pour le DSP, je le ferais niveau logiciel, et donc, il faudrait que je vois comment fonctionne openAL pour reproduire ce mixage moi même, afin de pouvoir obtenir mes 300 voix.

Je pense que tu es surtout du genre à ne pas réinventer la roue et je suis curieux de voir si tu es capable de produire quelque chose qui soit plus efficace que les algos d'OpenAL. C'est peut-être le cas, mais si ça l'est, alors il faut en faire profiter la communauté.

Mais de toutes façons, tu n'auras pas à le faire. Comme dit plus haut, si OpenAL peut mixer proprement 255 sources, alors il peut en mixer 512 ou 1024. Le tout est que ça se fasse dans un délai raisonnable.

Donc le mieux que tu aies à faire, là tout de suite et pour ne pas perdre de temps, est :

• D'installer les dernières version d'OpenAL in situ sur la machine que tu vas utiliser ;
• D'adapter le programme de test filé en lien plus haut et d'examiner le résultat qu'il donne chez toi ;
• De récupérer les sources de la lib, de retrouver et modifier les bonnes constantes si besoin, et la recompiler si ça ne suffisait pas.