9 - Synthèse sonore et banques de sons

Salut, moi j'ai ça sur une debian jessie (LibraZiK) à jour ("gcc version 4.9.2 (Debian 4.9.2-10)") :

g++ -c -o src/generateSFZfromDir.o src/generateSFZfromDir.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.MakeVector.o src/lib/class.MakeVector.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.StringTools.o src/lib/class.StringTools.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.LocaleTools.o src/lib/class.LocaleTools.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.FilesystemTools.o src/lib/class.FilesystemTools.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.CommandLine.o src/lib/class.CommandLine.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.CsvFile.o src/lib/class.CsvFile.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.MidiTools.o src/lib/class.MidiTools.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.AudioFile.o src/lib/class.AudioFile.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.SfzFile.o src/lib/class.SfzFile.cpp -Ilib/ -lsndfile
g++ -c -o src/lib/class.HtmlKeyboardFile.o src/lib/class.HtmlKeyboardFile.cpp -Ilib/ -lsndfile
src/lib/class.HtmlKeyboardFile.cpp: In member function 'std::string HtmlKeyboardFile::GetHtml()':
src/lib/class.HtmlKeyboardFile.cpp:69:135: error: cannot pass objects of non-trivially-copyable type 'class std::basic_string<char>' through '...'
  if(!FilesystemTools::FileExists(pathResources+"/htmlColsDef.csv")){throw StringTools::sprintf("Error opening file %s.", pathResources+"/htmlColsDef.csv"); return "";}

Deux suggestions :
1) versionner ton tar.gz (genre zicToolsPm-0.1.tar.gz) parce que s'il y a plusieurs versions du programme (ce qui va certainement arriver) ça va être un joyeux boxon
2) mettre le code sur une forge accessible à tous pour permettre des propositions d'améliorations du code
3) virer les zicToolsPm.kdev4, .kdev4/* et src/.kdev4/* lorsque tu fais un tarball car j'imagine qu'il ne sont pas nécessaires.

Ton compilateur est plus strict que le mien mais il faut bien reconnaître qu'il a raison... Ca devrait être corrigé, ici :
http://maatala.free.fr/downloads/zicToolsPm-1-0-0.tar.gz

Comme tu vois j'ai mis la version ds le nom de fichier (je l'ai déjà ds le source src/lib/version.cpp).
Pour le partage des sources avec un système de gestion de version, oui, s'il y a des volontaires pour faire évoluer le développement ça sera nécessaire. J'attends de voir s'il y a du monde qui se propose pour ajouter/corriger/modifier...

Pour les fichiers kdev, oui, ça serait mieux qu'ils soient absents du tar, mais kdev les crée à cet endroit et j'en ai besoin. Donc je ferai un petit script qui package le projet après les avoir momentanément déplacés ailleurs, et les remet ensuite à leur place. Mais ça c'est ma cuisine locale

Ceci est interessant.
quelques questions me viennent à l'esprit :

- comment le programme choisit il sur quelles notes placer les echantillons ?
- cherche t'il des loops dans les echantillons ?

Pour le choix des notes, il y a une analyse du nom de fichier, qui cherche la note midi dans le début du fichier (genre '53guitare.wav', '42-guitare.wav', etc.). C'est codé en dur car si j'ai bien compris l'utilisation d'expressions régulières requiert C++11, je n'ai aucune idée de ce que ça peut signifier pour les utilisateurs sur des systèmes un peu anciens. Si quelqu'un peut m'éclairer là-dessus (ça fait presque 20 an que je n'ai pas fait de c++, j'ai un peu perdu le fil...)
Avec une expression régulière ça pourrait devenir une option du script, chacun pourrait spécifier comment retrouver la note dans les noms des fichiers.
Bon, ensuite il y a la reconnaissance automatique par analyse du signal...
Si aucune note n'est détectée dans le nom du fichier, le sample est placé là où il y a de la place sur le clavier, en partant de la note 0 et en remplissant les trous laissés par les samples pour qui une note a été trouvée et qui, eux, sont placés sur leur note quoi qu'il arrive.

Pour les loops, non, rien de tel. C'est plutôt orienté échantillons instrumentaux pour l'instant. D'ailleurs le sfz généré est basique dans ses options (un groupe, one shot). Il faut le compléter à la main si on souhaite appliquer une enveloppe ou autres.
Par contre il serait faisable de détecter la partie stationnaire du signal pour éventuellement créer des loops (violons qui tiennent la note pendant 3 heures, par exemple...)

Tous les instruments à son entretenu (violons, soufflants, orgues, tremolos et autres roulements), et donc potentiellement 95 % des sons orchestraux nécessitent en effet de pouvoir paramétrer des points de bouclage.

Détecter la partie stationnaire, si c'est possible serait insuffisant pour obtenir de bons points de bouclage.

C'est toujours très délicat de trouver des points de bouclage qui marchent. en effet, dans 90 % des cas, le bouclage génère un clic audible, même lorsqu'on à pris le soin de veiller au 0 crossing de ceux ci (que les deux points soient bien calés sur un passage du signal à 0 db, dans le meme sens).
Et lorqu'on a pas de clics, reste encore à ne pas générer de vibrato incongru.
Bilan, pas loin d'une vingtaine d'essais sont nécessaires, même avec des outils d'aide à la recherche de similitude de courbes d'entrée et de sortie de boucle.

Donc ranger correctement les échantillons dans la soundfont est un gain de temps appréciable, mais ne suffira pas à créer une banque de son exploitable.

Concernant la détection de la partie stationnaire, j'avais fait un truc très basique il y a quelques années, où je détectais le point ou le signal passe au-dessus de 80% (ou 90) de sa valeur maximale, et le point où il repasse en-dessous de 80%. C'est simpliste, ça présuppose une enveloppe A-S-R sans decay. Mais en l'occurrence c'était pour faire de la synthèse granulaire, donc ça me suffisait.
Pour le 0 crossing, ma première idée serait de faire un "mix" en appliquant une enveloppe au loop finissant pour le faire tomber rapidement à zéro (release), et dans le même intervalle de temps une attaque sur le loop qui arrive. Ca risque de faire un petit effet chorus sur cet intervalle de chevauchement, et de plus je ne sais pas si les samplers savent faire ça.
En fait je n'ai jamais trop exploré la partie loop de linuxsampler (c'est lui que j'utilise jusqu'à présent), ce que j'ai fait avec linuxsampler jusqu'à présent utilisait essentiellement des staccati et des percussions (roulements suffisamment courts pour le pas avoir besoin de loop).
Pour en revenir au programme que j'ai posté hier, c'est ouvert, si quelqu'un est d'attaque pour intégrer des fonctions supplémentaires (pitch tracking, détection de sustain), il est le bienvenu...

Je confirme, ça compile bien maintenant.



Comme tu veux. Moi j'aurai tendance à faire l'inverse, c'est à dire mettre les sources sur une forge en ligne et filer le lien ici pour permettre à des gens de participer. Mais tu fais bien comme tu veux





Autre demande : y'a un problème avec l'installation. Pour l'instant, ton exécutable doit être mis dans le PATH et il trouve ses petits de cette façon. Là, j'ai commencé à l'empaqueter (.deb) pour faire ça proprement, et du coup, je me retrouve face au FHS (standard d'emplacement des différents fichiers). Le binaire est donc placé dans /usr/bin/ et il ne retrouve plus ses petits puisqu'ils sont censés se trouver dans un sous répertoire de là où est le binaire.

Le problème ici est que le standard FHS ne permet pas de placer des fichiers non-binaires dans /usr/bin/ et qu'il faudrait que ceux-là se trouvent dans /usr/share/zictoolspm/ et donc, que le binaire s'attende à les trouver là bas.

Tu peux faire quelque chose pour ça ?

Oui, je n'ai pas visé l'install standard dans un premier temps. En plus je ne suis pas un pros de l'empaquetage, donc si tu peux prendre l'empaquetage en charge, je fais les changements de code associés !
Dans la foulée, si tu peux me dire où doivent aller les fichiers de config et de paramétrage qui se trouvent sous inst/locale et inst/resources. Est-ce qu'ils vont tous dans /use/share/zicToolsPm? Il y a un peu de tout là-dedans : des images, des squelettes de fichiers HTML, quelques données de config (qu'il faudrait regrouper dans un fichier de config unique) et aussi tous les textes qui dépendent de la langue (aide en ligne et traduction des messages, j'imagine que l'aide en ligne devrait être installée en "man").

L'autre truc à garder en tête pour l'empaquetage, c'est que je prévois d'ajouter d'autres exécutables que j'ai plus ou moins déjà. Donc à terme le paquet contiendrait plusieurs exécutables (donc plusieurs aides en ligne). Est-ce conforme au FHS, ou bien faudra-t-il faire autant de paquets que d'exécutables ?

Super. Pas de soucis pour moi, je vais t'aider à ça. Vu que j'essaie au maximum de coller aux règles d'empaquetage de debian, ça facilitera le travail des empaqueteurs des autres distributions puisqu'ils suivent le même genre de règles (FHS et compagnie).




Allons-y.

Alors premièrement, j'ai l'impression (en regardant dans mon /usr/share/) qu'il ne faut pas de majuscules dans le nom du répertoire. Ce serait donc /usr/share/zictoolspm .

Tu peux y mettre à peu prêt tout ce qui est destiné à être utilisé de base par tous les utilisateurs d'un système (images, squelettes, fichiers html, config, textes de traduction...). C'est le "system-wide".

Si les fichiers de config' sont destinés à être modifiés par les utilisateurs, il faut pouvoir faire en sorte qu'ils soient accessibles et modifiables "user-wide". La plupart du temps, les paquets-logiciel installent les réglages par défaut dans /usr/share/lelogiciel/ et les réglages-utilisateurs dans ~/.config/lelogiciel/. Lorsque l'on lance le logiciel, il regarde si quelque chose se trouve dans ~/.config/lelogiciel/ et, si rien ne s'y trouve, il utilise ce qui se trouve dans /usr/share/lelogiciel/ . Si un utilisateur veut modifier la configuration par défaut, il peut donc le faire à l'aide des fichiers dans ~/.config/lelogiciel/ et ceci à l'avantage de lui permettre de changer les configurations pour cet utilisateur, sans que cela n'impacte sur d'autres utilisateurs du même système. Un autre avantage est que ça permet à l'utilisateur de pouvoir modifier les paramètres sans avoir besoin pour cela des droits d'administration du système (root) nécessaires à la modification de ce qui se trouve dans /usr/share/ .

Pour la page de man, c'est dans un autre dossier : /usr/share/man/ . Pour ce qui me concerne ici (empaquetage méthode debian), tu n'as pas besoin de t'embêter à l'auto-installer, je peux le faire facilement avec les méthodes d'empaquetage de debian. Ceci dit, si tu veux faire ça proprement pour un utilisateur qui compilerai et installerai lui-même ton logiciel, alors /usr/share/man/man1/ (pour la page de man en anglais) est le chemin à suivre.




Ça n'a pas de rapport avec le FHS. C'est plutôt du côté des méthodes d'empaquetage des différentes distributions. Tu n'as pas à t'embêter avec ça en tant que "codeur", c'est un boulot qui revient à l'intégrateur/empaqueteur. Par exemple chez Debian, l'idée générale est de ne pas forcer l'utilisateur à installer des trucs dont il n'a pas besoin. Donc, séparation des paquets. Ceci dit, si ce sont des "petits outils", ça peut rentrer dans le cadre d'une "suite de petits outils" et donc être dans un paquet unique. Mais encore une fois, c'est une tâche pour l'empaqueteur, pas pour le codeur amont.

On pourra en discuter quand le besoin sera là (= quand tu auras plusieurs binaires dans ton paquet source) car ceci dépendra de pas mal de choses dont des relations de dépendance (ou pas) entre ces différents binaires et leurs relations aux fichiers de configuration (par exemple : un fichier de conf unique pour tous les binaires / un fichier de conf par binaire ?).

Voilà, j'espère t'avoir éclairé. Si tu as des questions, dis moi.

Oui, j'ai songé à la question des majuscules après coup. Je vais rebaptiser l'ensemble. Tant qu'on en est au tout début, c'est le moment ou jamais.
Je te dirai quand j'aurai changé le code. Dans un premier temps je dirais qu'on fait l'impasse sur la config perso dans ~/.config. Ca peut être ajouté après, mais auparavant je préfèrerais avoir un/des fichiers de config un peu mieux organisés qu'aujourd'hui.

A priori je vois l'ensemble zictoolspm comme suite d'utilitaires qui s'appuient sur un même framework (tout ce qui est dans src/lib). Par contre certains utilitaires demandent des librairies en plus que d'autre (libxml, libzip et libsndfile sont ou ne sont pas nécessaires suivant ce qu'on veut faire), et c'est toujours pénible d'avoir à installer des libs dont on n'a pas besoin. Mais j'imagine que ce genre de truc est plutôt de l'ordre du makefile.

Pour la conf des différents logiciels, je verrai en faisant... Je m'attends à une partie partagée et une partie par logiciel. Pour l'instant je penche vers un fichier de conf unique avec des sections, car la partie partagée sera assez importante. A voir en temps utile...

Question : tu as une forge à conseiller pour la mise en ligne des sources ?

OK. J'attends impatiemment le prochain code source pour pouvoir finir l'empaquetage pour LibraZiK (= debian jessie).



De l'ordre du makefile pour s'il y en a besoin à la construction. Si c'est uniquement au runtime qu'ils sont nécessaires, alors c'est du domaine de l'empaquetage (ajout de dépendance au paquet).




OK, du coup, alors ça serait un paquet global de la "suite des outils zictoolspm".




Pas mal de gens utilisent github car il est pratique, à le vent en poupe, est plutôt sexy, ... mais c'est pas libre.
Sourceforge est sur le déclin.
Pour d'autre, y'a gitlab il me semble, ou alors tu peux même aller chez tuxfamily, ils ont du git, tu pourras avoir pas mal de truc au choix (genre espace web, bdd, liste de diff,...) et ils sont français (cocorico .

J'ai pas de conseil spécial à donner à ce niveau là. Si j'avais à le faire moi même, j'hésiterai entre github ("the place to be" / pas libre) et tuxfamily (un peu plus underground, mais libre et fr).

Bonsoir !

voici une nouvelle version qui devrait améliorer l'installation. Ca se trouve là :

http://maatala.free.fr/downloads/zictoolspm-1.0.2.tar.gz

Ca contient le renommage en minuscule du nom du projet (partout), la mise au carré des fichiers de configuration, l'installation sous /usr/bin et /usr/share/zictoolspm pour la config, la prise en compte prioritaire d'une config sous ~/.config/zictoolspm et un tar.gz sans fichiers de développement parasites...

J'essaierai de trouver le temps de mettre ça sur une forge ce week-end...

Super, je regarde ça et te tiens au courant.

Si tu veux jette peut-être un oeil au makefile, surtout pour les 3 lignes d'install. Je suis passé de c++/windows à php/linux il y a plus de 15 ans, autant dire que mes compétences en makefile sont au ras des pâquerettes...

OK, c'est empaqueté. Il va falloir que je fasse des tests maintenant pour comprendre comment l'utiliser.
Je te tiens au jus.

N'hésite pas à poser des questions... Je suis en train d'ouvrir un projet chez tuxfamily donc la doc sera bientôt accessible en ligne. Si ça n'est pas clair on pourra la corriger.

ok

Pas eu le temps de tester davantage pour le moment, mais je viens de retomber sur ceci http://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored et je me suis dis que ça pourrait t'intéresser peut être.

Salut à tou(te)s,

Je viens de mettre en ligne une nouvelle version de zictoolspm. Ca se trouve là :

https://svn.tuxfamily.org/viewvc.cgi/zictoolspm_zictoolspm_svn/

Ca contient un second programme, qui complète le premier, et génère lui aussi des sfz et des pdf, mais cette fois-ci en s'appuyant sur une liste d'échantillons stockée dans un fichier LibreOffice Calc. L'idée est de générer une fois pour toutes un gros csv avec tous mes échantillons grâce au premier script generesfz_fromdir, de l'importer sous LibreOffice calc, et de passer quelques heures à documenter les échantillons à la main (on n'y coupe pas, de toute façon) en indiquant en particulier l'instrument et éventuellement la note. Bref, on bichonne sa base de données d'échantillons sous LibreOffice calc, on la conserve précieusement, quite ensuite à la corriger, à la compléter lorsqu'on récupère une nouvelle banque de sons...
Ensuite, on la fait lire par ce second script (generatesfz_fromods), qui va produire un sfz par instrument, indépendamment de l'emplacement physique des échantillons. Ca permet de faire des choses comme :
- par exemple, regrouper toutes les caisses claires (ou kicks, ou high-hat) des banques Hydrogen dans un snare.sfz, kick.sfz, highhat.sfz...
- pour un instrument dont on n'a pas toutes les notes, définir le pitch shifting avec lequel le sampler produira les notes manquantes.
- regrouper différents modes de jeu du même instrument, ou différents instruments de même famille avec un registre pas trop étendu, dans un même sfz (à condition que ça loge dans les 128 notes midi).

J'espère que ça compile et que ça marche partout... Ca nécessite libxml2 et libzip désormais.

Toujours sur LibraZiK, j'ai ça :

...
...
...
cpp -Ilib/ -I/usr/include/libxml2 -lsndfile -lzip -lxml2
src/lib/class.CsvFileODSDatasheet.cpp: In member function 'bool CsvFileODSDatasheet::ReadODSFileIntoXmlRawContent()':
src/lib/class.CsvFileODSDatasheet.cpp:160:51: error: 'ZIP_RDONLY' was not declared in this scope
  zip *z = zip_open(this->filePathAndName.c_str(), ZIP_RDONLY, &err);
                                                   ^
makefile:40: recipe for target 'src/lib/class.CsvFileODSDatasheet.o' failed
make[1]: *** [src/lib/class.CsvFileODSDatasheet.o] Error 1
make[1]: Leaving directory '/tmp/buildd/zictoolspm-1.0.3'

Quelques autres remarques et suggestions :

• tu dis dans ton INSTALL qu'il faut que "html2pdf" soit installé. Je ne sais pas/plus sous quel système tu fonctionnes, mais j'ai pas de paquet "html2pdf" sous Debian, et j'ai pas trouvé non plus de paquet fournissant un binaire du nom de "html2pdf". Tu peux m'en dire un peu plusse ?
• tu sembles avoir oublié de mettre une entrée pour la version 1.0.3 dans ton fichier VERSION
• ça serait super si ton makefile pouvait prendre en compte un répertoire d'installation voulu par l'utilisateur (la variable du nom de PREFIX semble être un standard) par exemple, l'utilisateur pourrait installer avec un :

  make install PREFIX=/usr

Voilà, j'espère que ça aide, dis moi.