Picoloop est un séquenceur musical que je développe depuis 2013. Ce logiciel est une « groovebox » logicielle permettant de jouer des séquences de 16 pas. Chaque pas peut contenir une note et un ensemble de paramètres permettant de modifier la tessiture du son joué.
Ce logiciel permet de créer de la musique à partir d'un ordinateur Linux/Windows ou d'une console de jeu PSP, GP2X, Dingoo. Il s'inspire fortement des logiciels Nanoloop (non-libres) développés par Oliver Wittchow un Allemand spécialiste du développement de séquenceur sur GameBoy, GameBoy Advance et Android.
Picoloop est en licence BSD.
Sommaire
- Histoire de Picoloop
- Séquenceurs menu et affichage
- Plateforme
- Moteur de synthèse
- Code source et binaire
- Exemples de production
- Licence
Histoire de Picoloop
En 2010, j'ai découvert deux logiciels qui ont modifié sur le long terme mon approche de la musique.
Nanoloop
Le premier, Nanoloop, est un séquenceur synthétiseur embarqué dans une cartouche de GameBoy Advance permettant de jouer de la musique électronique. Pour de nombreux utilisateurs, ce logiciel dont je m'inspire très fortement dispose d'une ergonomie tout simplement parfaite.
Je qualifierai même d'oeuvre d'art ce logiciel sur un point de vue ergonomique mais aussi sur ses nombreuses qualités d'un point de vue musical.
Il permet entre autres de jouer quatre pistes monophoniques en stéréo. Il s’intègre avec des instruments midi. Il permet de créer une musique tout à fait cohérente et travaillée.
LGPT
Le second, LGPT, est un séquenceur échantillonneur s'inspirant des trackers des années 90 que l'on trouvait sur Amiga, Atari et DOS. Ce logiciel fonctionne sur de nombreuses consoles portables sous Linux et permet de jouer 8 pistes contenant des samples.
Le label http://www.hexawe.net/ publie des albums qui sont composés uniquement avec ce logiciel. D'ailleurs, la plupart des musiques des albums sont publiées avec le fichier LGPT associé.
Picoloop
Après deux années à me balader avec ces deux logiciels dans mon sac à dos, je me suis dit : « je suis capable de développer mon logiciel, qui répondra à mes besoins et souhaits ».
Je connaissais la programmation C/C++ sous Linux mais je n'avais encore jamais développé de logiciel graphique et sonore sur des plateformes embarquées. J'ai donc commencé à bricoler divers main.c. Je suis arrivé à mettre en place une interface graphique et lui faire jouer des plips et des plops. J'ai porté cette interface sur la plateforme Dingoo, une console portable sous Linux. Et là… je suis clairement tombé dedans.
Séquenceurs menu et affichage
Le séquenceur propose 4 pistes dans lesquelles on retrouve des patterns (les séquences).
Voilà à quoi ressemble le séquenceur graphiquement :
L'affichage est composé de trois élements :
- le séquenceur dans une matrice 4x4 de 16 pas
- le menu situé en bas, les crochets indiquent le menu sélectionné
- les infos courantes situées à droite
- les pas 1, 7, 10 et 15 seront joués.
- le cutoff et la résonance sont les paramètres en cours de modification, on peut le voir sur la deuxième ligne de texte à droite
- la tête de lecture du séquenceur se trouve au pas numéro 8 en vert sombre affiché également à droite (numérotation commençant à 0).
- le curseur de sélection se trouve sur le pas 7 en vert clair et je suis en train de modifier la hauteur du cutoff et de la résonance pour ce pas.
Le séquenceur
Il permet de jouer de 16 à 128 pas par piste.
BPM
Le BPM (vitesse de lecture en Beat Par Minutes) et le swing (décalage temporel du temps des pas), peuvent être modifiés globalement pour les 4 pistes, en fonction du type de musique que l'on souhaite créer.
Swing
Le swing, parfois appelé groove dans certains séquenceurs, permet de modifier la vitesse de lecture des pas pairs et impairs. Picoloop permet de modifier ce swing de 25 à 75 pour les quatre pistes simultanément.
- Un swing à 50 donne le même temps de lecture pour chaque pas, on a donc une vitesse de lecture homogène entre les pas.
- Un swing à 75 permet de lire les pas pairs deux fois plus vite que les pas impairs.
- Un swing à 25 permet de lire les pas impairs deux fois plus vite que les pas pairs.
TimeDivision
Chaque piste peut profiter d'un temps de divisions temporelles différent. Cela permet de faire varier la vitesse de lecture d'une piste par rapport à une autre. L'utilité pratique d'une telle fonctionnalité est de créer de longues nappes de synthé que l'on fait varier très lentement. Par exemple un temps de division de 8 permet de lire une piste de 16 pas à la même vitesse qu'une piste de 128 pas. Ce qui est très pratique, mais finalement peu disponible dans les séquenceurs à pattern.
Ergonomie du séquenceur
La modification d'un pattern s'effectue en temps réel pendant que le séquenceur joue le pattern. L'ensemble des paramètres de synthèse de chaque synthétiseur peut être modifié pour chaque pas, ce qui donne une variation élevée du son joué par un pattern. Cette ergonomie est similaire à Nanoloop et est proche des séquenceurs Elektron.
Chargement et sauvegarde des patterns
Un menu Load/Save permet de sauvegarder le pattern qui est actuellement joué sur une piste. On peut si on le souhaite sauvegarder et charger indépendamment chaque piste et non les quatre en même temps. Ce qui permet de faire des micro-variations dans ce que l'on joue.
Le chargement d'un pattern s'effectue en temps réel et non à la fin d'un pattern. Cette méthode adaptée au jeu en temps réel, et utilisée typiquement sur les synthétiseurs Volca, augmente le panel de variations possible que l'on peut appliquer à des patterns de 16 pas.
Plateforme
J'ai développé Picoloop pour qu'il fonctionne sur des consoles de jeu mais aussi sur PC.
L'idée est assez simple, je souhaitais :
- disposer d'un bloc-note musical avec moi ;
- pouvoir utiliser les pistes créées sur ce bloc-note directement avec mes synthés mais aussi sur un CPU ayant des performances supérieures aux consoles de jeu ;
- disposer d'un code ayant une portabilité élevée afin de pouvoir le faire évoluer vers les nouvelles plateformes qui sortiront dans le futur ;
Picoloop fonctionne donc sur Linux, Windows mais aussi sur les autres plateformes sur lesquelles j'ai eu le temps de le porter.
Le choix des bibliothèques utilisées par le code du logiciel a été effectué dans un souci de portabilité. J'utilise SDL 1.2 pour l'affichage car SDL 1.2 est encore disponible sur beaucoup de plateformes. RtAudio pour la gestion du son et RtMidi pour la partie Midi (en cours de développement et partiellement implémenté).
PSP et Dingoo
Ici une photo de Picoloop sur plateformes Dingoo avec le système Linux OpenDingux et PSP avec un firmware permettant l’exécution de homebrew (code "maison").
Moteur de synthèse
Picosynth
Un synthétiseur soustractif 32 bits 2 oscillateurs utilisant uniquement des entiers que j'ai développé spécialement pour valider le concept de l'application dans un environnement sans virgule flottante. Il utilise une synthèse soustractive très simplifiée. Il permet de jouer des sons très simples.
Picodrum
Un synthétiseur soustractif 32 bits dédié aux rythmes. Il s'inspire très fortement du moteur Picosynth. Il permet de jouer des "kicks", des "hats" et des "snares".
DBOpl
Un synthétiseur FM 2 opérateurs utilisant un code source d'émulation de carte OPL2. Ce type de synthèse était utilisé typiquement sur les jeux DOS.
Cursynth
Un synthétiseur soustractif 2 oscillateurs développé par Matt Tytel disponible également sous Debian en ligne de commande.
Twytch
Également appellé Helm, un synthétiseur soustractif 2 oscillateurs développé également par Matt Tytel. Ce synthétiseur est plus complet et plus varié que Cursynth.
PBSynth
Encore un autre synthétiseur soustractif 2 oscillateurs. Ce synthé a été développé il y a plusieurs années par un amateur de développement logiciel et de musique, à la base pour la plateforme GP2X. Celui-ci occupe très peu de CPU, il fonctionne en entier et virgule flottante et peut être joué sur une console de jeu type PSP.
MDA Drumsynth
Un synthétiseur rythmique développé par la société MDA qui l'a mis en opensource par la suite.
Code source et binaire
Le code source de ce logiciel est hébergé sur GitHub. Le forum du développement du logiciel se trouve hébergé sur chipmusic.org. La dernière version des binaires pour Windows et PSP se trouve sur Dropbox.
Étant seul sur le développement de ce projet que j'effectue par passion, je n'ai pas créé de paquets pour Debian, Redhat et autres versions de Linux. Cependant le logiciel n'est pas compliqué à compiler et le README contient les instructions liées à la compilation sous Linux. Si vous souhaitez contribuer à la création d'un paquet pour votre distribution préférée vous êtes bien évidemment les bienvenus.
Si vous souhaitez contribuer à ce logiciel, je vous invite à soumettre vos diffs au format "diff -Naur" directement dans la partie "issue" dans Github en précisant le tag git sur lequel s'applique ce patch.
Exemples de production
Les deux premiers lien musicaux utilisent Open303 et Cursynth qui sont des synthèses qui demandent une FPU très puissante : comprendre PC desktop ou laptop supportant au moins SSE et fournissant 1 Gflops. Un PC laptop bas de gamme d'il y a quatre ans en est capable.
En clair le code utilisé tourne sur PC et il n'est pas optimisé suffisamment pour tourner sur de l'embarqué, il demande à vue de nez 500 Mflops pour fonctionner correctement par piste, et il y a quatre pistes. Ces tracks n'ont pas été testés sur processeur ARM avec NEON mais les processeurs ARM tablette et smartphone ne sont probablement pas encore en mesure de gérer suffisamment de FLOPS en CPU pour arriver à soutenir 4 voix avec un calcul flottant de ce type.
Le troisième utilise picodrum, picosynth et Dbopl, en gros ce qu'il est possible de sortir sur une PSP ou une Dingoo avec du calcul entier (int long) et pas de FPU. C'est une synthèse moins couteuse que les deux tracks précédentes.
Licence
Dialogue entre un attentif modérateur et l'auteur :
« Concernant la dépêche sur Picoloop en cours de modération sur LinuxFr.org : d'abord merci d'avoir rédigé et soumis une dépêche sur LinuxFr.org. L'équipe de modération s'interroge sur une information manquante qui est généralement attendue par nos lecteurs, à savoir la licence du logiciel.
Après un examen rapide, je dirais, sauf erreur, concernant le dépôt Git :
- rien dans le README global
- amsynth/ : GPLv2+
- biquad_filter/ : licence libre basique
- chip/gb : GPLv2
- chip/opl2 : GPLv2+
- PGCPE : licences propriétaires (dont "Not for reproduction (electronic or hardcopy) except for personal use." par exemple). Ça paraît problématique.
- cursynth: GPLv3+ (potentiellement un souci avec le GPLv2 strict vu plus haut)
- lgptsampler : GPLv2+
- mda_drumsynth : GPLv2+
- midi : une BSD modifiée avec une demande optionnelle d'envoi des modifications
- open303 : pas d'info de licence, propriétaire donc
- pbsynth : pas d'info de licence, propriétaire donc
- picoloop : non concluant, a priori un mélange de licences plus du non spécifié
- twytch : GPLv3+
- vopm : non concluant, je dirais propriétaire
La dépêche évoque Picoloop, Picosynth, Picodrum, DBOpl, Cursynth, Twytch, PBSynth et MDA Drumsynth. Pourrait-on connaître la licence de chacun de ces logiciels ? Idéalement l'ajout d'un fichier COPYRIGHT contenant la licence dans chaque répertoire, la mention de la licence dans le README et l'utilisation d'entêtes serait pratique pour déterminer la licence de chaque code. Voir par exemple http://www.gnu.org/licenses/gpl-howto.fr.html pour la GPL. »
La réponse courte
Je vais placer une licence BSD sur le répertoire Picoloop, le code source du logiciel. Ça me semble le plus adapté en fonction de la façon dont je développe ce logiciel. Si une personne souhaite le reprendre un jour il pourra le faire évoluer vers un type de licence plus adapté au cycle de vie de ce logiciel. Je vais intégrer un fichier LICENCE en fonction de ce que j’aperçois dans chaque répertoire, tu as déjà fait un gros bout du boulot. Je répond à ce mail une fois que c'est effectué avec le nom des fichiers et les explications du pourquoi.
La réponse longue
Tu soulèves une question très intéressante mais aussi très longue à détailler et expliquer, j'ai toujours repoussé à plus tard et je n'aurais sans doute pas dû.
Je me suis intéressé uniquement à l'aspect conception du logiciel, les licences pour moi c’était annexe tant que le code semblait être BSD, GPL, MIT et autres licence opensource. Je n'ai toujours pas tranché très clairement la licence qui peut s'appliquer au programme en lui même pour différente raison que je vais décrire. Je vais donc partir par défaut sur la BSD.
Tout d'abord je vais détailler un peu le dépôt github.com/yoyz/audio :
- Le répertoire "." du git contient les codes sources d'origine sans modification
- Le répertoire "picoloop" du git contient le programme Picoloop et ses dépendances pour compiler avec gcc/g++ make, en clair le minimum vital pour ne pas avoir à ramener 15 dépendances pour que le binaire puisse fonctionner.
Je ne travaille que dans le répertoire "picoloop" du git pour faire évoluer le logiciel et patcher les moteurs sonores. Je travaille dans le répertoire "." du git pour importer des moteurs sonores. C'est pour ça d’ailleurs que le git s'appelle « audio » et non « picoloop », car un jour j'y ajouterai d'autres programmes qui dépendront de ces moteurs de synthèse. Les imports de code de moteurs de synthèse se font dans le répertoire "." afin de garder une trace des sources originales. J’intègre au final dans Picoloop quand un moteur sonore est fonctionnel tel quel avec un "build.sh" et un "main.c" permettant de valider un helloworld dessus. Par exemple je n'utilise pas encore VOPM, ni PGCPE, enfin celui-ci il va falloir que je creuse pour savoir où il se trouve j'en ai pas de souvenir.
Ensuite le programme Picoloop dans le répertoire du même nom est scindé en deux grosses briques :
- le séquenceur qui utilise les bibliothèques RtAudio, RtMidi, SDL1.2, DirectX ;
- les plugins moteurs de synthése qui sont dans des licences très variées comme tu as pu le voir.
L'ensemble des .c/.cpp du répertoire picoloop et des répertoires fils sont compilés dans des .o. J'ai donc besoin de l'ensemble des codes des moteurs de synthèse que j'utilise et du séquenceur pour fabriquer le binaire. Il n'est pas possible d'utiliser des .so et donc de désolidariser chaque bout de code, bien que ce soit portable sous Unix, car la PSP ne les prend pas en charge de la même façon, Windows également. Et donc ça demanderait pas mal de boulot pour arriver à un résultat incertain. Donc, pragmatiquement, je suis obligé d'avoir l'ensemble des codes sources pour que ça fonctionne. Et tout ces codes sources dans des licences variées.
Je penche fortement du coup pour une licence BSD pour Picoloop, ce qui laisse à quiconque le soin de faire ce qu'il souhaite des sources sans se préoccuper trop de l'aspect juridique lié aux licences. Pour la simple raison que si la GPL2 est sans doute incompatible avec la licences MIT qui est incompatible avec la tataouinepouetpouet licence, ça ne m’intéressera absolument pas. Qu'est ce que tu en penses vu la construction du soft ?
Dans le monde de la MAO, il y a peu de codeurs (moins de 10) par projet et le code source tombe très souvent aux oubliettes au bout de quelques années. Et avec ce prérequis d’insérer un lot de .h et de .o avec licences variées dans un exécutable, le mieux serait peut-être qu'il soit en BSD au final afin de tout simplifier. Mon intérêt c'est de faire un logiciel qui me plaît et qui plaît aux gens ; si un jour je souhaite faire de l'argent avec, ou si une autre personne souhaite faire de l'argent avec, que ce soit faisable sans devenir un casse-tête juridique. Je pense donc que laisser les sources sans patch et avec patch dans le même arbre ça peut aider à démystifier ce casse-tête, s'il se présente un jour.
Concernant les moteurs de synthèse dont la licence semble problématique voici ce que j'ai trouvé :
- Open303 : MIT
- PGCPE : celui-ci je ne l'ai pas vu dans mon code ? Je ne pense pas l'utiliser, il doit traîner dans le "." du git — enfin ça ne me dit rien, mais c'est sans doute un bout de code qui suit un autre bout de code. Très souvent des moteurs sonores sont publiés par des codeurs indépendants sur leur page personnelle. On retrouve très souvent ces bouts de code avec des émulateurs qui sont publiés avec leurs source. D'ailleurs j'encourage tous ces petits gars à publier leur code, même s'ils ne fournissent pas l'infra ./configure et autre pour que ça tourne, juste un bout de code permettant une réutilisation.
- Pbsynth : le code a été publié avec le binaire Linux Gp2x sur le site Openhandleds. L'auteur ne répond plus à ses courriels, il a sans doute changé d'adresse. Je ne saurais dire quelle est la licence de ce bout de code logiciel, l'auteur a laissé les sources et le binaire volontairement sur le site Openhandhelds. En suivant le fil du README, je pense qu'il ne s'est jamais plus préoccupé de la suite des événements, même s'il a songé un jour à en faire un produit. Donc je ne sais pas, je l'ai contacté, il y a plus d'un an, il ne m'a jamais répondu.
- Vopm, je viens de lui envoyer un courriel sam_kb CHEZ yahoo.co.jp, c'est un Japonais qui publie des VST freeware pour Windows avec le code source, et là je ne sais pas quel est la licence et j'avoue ne pas lui avoir posé la question précédemment ; je n'utilise pas son code source dans Picoloop, du moins pas encore, mais j'y songe.
Du coup, si je résume
- Open303 utilise une licence MIT, et il est utilisé dans le code
- PGCPE il faut que je creuse, sûrement dans le "." du git, mais pas dans Picoloop le logiciel ;
- Picoloop, on va dire BSD pour que rien ne coince, je vais mettre un fichier LICENCE ;
- Et concernant ces logiciels qui se trouvent dans "picoloop/Machine" (les moteurs de synthèse) :
- Picoloop : BSD
- Picosynth : BSD
- Picodrum : BSD
- DBOpl : GPLv2 audio/picoloop/Machine/Dbopl/adlib.h
- Cursynth : GPLv3
- Twytch : GPLv3
- PBSynth : je ne le saurais sans doute jamais
- MDA Drumsynth : opensource, mais quelles licences ? sur Sourceforge ils disent GPLv2 et MIT, mais je n'en suis pas certain.
Je viens de mettre à jour le git avec tes recommandations.
Voici l'arbre des licences :
| dossier | licence |
|---|---|
| picoloop | BSD |
| picoloop/Machine/MidiOutSystem | BSD |
| picoloop/Machine/Cursynth | GPLv3 |
| picoloop/Machine/Twytch | GPLv3 |
| picoloop/Machine/Dbopl | GPLv2 |
| picoloop/Machine/MDADrum | GPLv2 |
| picoloop/Machine/Open303 | MIT |
| picoloop/Machine/PBSynth | Inconnue ; l'auteur a disparu dans la nature |
| picoloop/Machine/Picosynth | BSD |
| picoloop/Machine/Picodrum | BSD |
Tout le reste du repo git, le répertoire "." n'est pas lié au logiciel Picoloop. J'y dépose ce dont j'ai besoin pour travailler, mais on peut construire le logiciel rien qu'à partir du répertoire "picoloop".
C'est donc lié à ma méthode de travail et lié à la construction du logiciel.
Du coup, seul PBSynth pose un souci et je ne vois pas bien comment résoudre ce problème.
Aller plus loin
- Sources (363 clics)
- Forum de développement (147 clics)
- Téléchargement des versions compilées (259 clics)
- README (139 clics)
- Exemple de production musicale n°1 (644 clics)
- Exemple de production musicale n°2 (275 clics)
- Exemple de production musicale n°3 (239 clics)
# Quelques réflexions
Posté par zurvan . Évalué à 5.
Tout d'abord, bravo pour ce projet !
J'avais déjà entendu parler de nanoloop, mais je ne l'ai jamais utilisé jusqu'à présent, même si j'essaye de tester tous les trackers existants. Sur Gameboy, j'utilise LSDJ, qui a d'ailleurs inspiré LittleGPTracker.
Pour bien profiter de picoloop, je pense qu'il faudra lire le manuel de nanoloop, parce que le readme n'est pas suffisant si on souhaite s'en sortir dans les combinaisons de commandes. Par exemple j'ai perdu mon premier essai (rien de grave hein) parce que je pensais que la sauvegarde serait plus intuitive, mais j'ai chargé un slot vide au lieu de sauvegarder (boutton B+bas)
En tout cas les sons sont intéressants, et je suis impatient de regarder du côté de la synthèse OPL et de produire mon premier morceau avec PicoLoop…
J'espère qu'il sera aisé à compiler sur debian arm et que picoloop aura ainsi sa place à côté de pico-8 sur le PocketCHIP ;)
Sinon, un émulateur android PSP devrait peut-être faire l'affaire pour l'avoir sur un appareil mobile (type téléphone ou tablette). À suivre…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 4.
@zurvan, merci, ça fait plaisir à lire.
Je suis d’accord, le manuel de picoloop est très sommaire coté contrôle et ergonomie.
Celui de nanoloop contient beaucoup plus de détail.
Beaucoup de chose se recoupe entre nanoloop et picoloop. J’utilise nanoloop 2.7 actuellement et
je cherche à rester au plus proche de l’ergonomie de ce logiciel.
Coté synthèse FM le code OPL supporte pour l’instant deux opérateurs.
On peut choisir l’addition des deux opérateurs ou faire de la FM à deux opérateurs.
Le troisième lien musical est un morceau ou j’ai utilisé la synthèse OPL,
Il est enregistré à partir d’une dingoo a320 avec OS opendingux, donc Linux et sans aucun effet.
C'est donc le son qui sort de la console.
Si j’ai bien compris, le code OPL (que j’utilise dans picoloop et qui vient à l’origine de la team dosbox )
peut supporter une synthèse à 4 opérateurs.
Il faut basculer le chip en OPL3 et utiliser les registres émulé d’une certaine manière pour pouvoir utiliser les 4 opérateurs.
Malheureusement, j’ai de grosse lacune sur ce chip et j’ai du mal à identifier comment mettre en œuvre facilement
ces 4 opérateurs.
Si une personne maitrise bien ce code et les chip OPL2/OPL3 je suis preneur.
[^] # Re: Quelques réflexions
Posté par zurvan . Évalué à 5.
Je ne suis pas un expert, mais tu peux jeter un oeil sur le tracker Adlib Tracker II (libre) http://adlibtracker.net/ qui gère la puce OPL3. Par contre pour avoir 4 opérateurs ça utilise 2 instruments avec 2 opérateurs, je ne sais pas si c'est une pratique courante, une limitation du tracker ou de la puce.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 4.
Je pense qu'il faut que je regarde un peu comment c'est effectué dans ce tracker.
J'avais utilisé ce tracker et légèrement instrumenté le code pour afficher les registres qui me semblaient pertinent et essayer de comprendre comment ça fonctionnait en détail.
Je me souviens d'en être ressorti avec un gros mal de crane parce que je ne savais pas assez ce que je cherchais. Mais oui, avec quatre opérateur on peut sortir des sons encore plus intéressant car il y a un beaucoup plus de combinaison de modulator/carrier et on passe à quatre enveloppe au lieu de deux.
Je ne sais pas par contre si beaucoup de musique l'utilise, mais cette possibilité m’intéresse et je pense que je mettrai ça en place si je trouve comment.
Ca me donne envie de le faire ;)
[^] # Re: Quelques réflexions
Posté par zurvan . Évalué à 5.
Tu peux regarder également http://bisqwit.iki.fi/source/adlmidi.html c'est un player midi avec un rendu OPL3.
C'est libre, ça utilise le code OPL3 de dosbox, mais du coup c'est débarrassé de toute ce qui est autours donc ça sera peut-être plus simple à interpréter.
Sinon si tu arrives à le réutiliser, VOPM est également une synthèse FM à 4 opérateurs, c'est l'émulation d'une puce (YM2151) antérieure à OPL3 mais les sons sont assez similaires.
Beaucoup de musiques adlib de vieux jeux DOS en tout cas, et j'ai l'impression qu'il y a encore beaucoup de fanatiques de ces sons FM encore maintenant.
https://soundcloud.com/search?q=opl3
https://soundcloud.com/search?q=opl2
https://soundcloud.com/search?q=ym2151
https://soundcloud.com/search?q=ym2612 (puce de la megadrive)
Et des appareils électroniques étonnants destinés à la reproduction des sons depuis les puces d'origines : http://gimic.jp/index.php?Getting%20Started%20with%20G.I.M.I.C
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 3.
Mais ça me semble top ce truc.
Il faut que je regarde ça.
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 4. Dernière modification le 11 mai 2016 à 20:04.
Concernant la compilation ARM, je n'ai pas testé. Je pense que sur une debian ARM ou autre variante linux ça devrait passer, mais si tu arrive à le compiler je suis preneur d'info.
Le mieux est de partir à ce moment la sur le makefile linux qui est un makefile sans cross compilation et qui utilise gcc/g++ et de travailler sur un raspberry avec 512 MiB de ram car les moteurs de synthèse occupe environ 350MiB dans la version desktop.
Je ne l'ai testé à ce jour que sur x86 32 et 64 bit et mips 32 bit.
on peut le faire tourner sur moins de 32MiB sur dingoo, mais c'est une version light avec trois moteurs de synthèse.
[^] # Re: Quelques réflexions
Posté par zurvan . Évalué à 4. Dernière modification le 12 mai 2016 à 00:03.
sur mon raspberry pi (512 Mo de ram), j'ai ça comme erreur :
et pas de binaire.
(edit) : g++ --version
g++ (Debian 4.6.3-14+rpi1) 4.6.3
je lis ici que ça devrait passer avec g++ 4.7 :
http://stackoverflow.com/questions/14674597/cc1plus-error-unrecognized-command-line-option-std-c11-with-g
Question, pourquoi le binaire au final (lorsque ça compile, sur x86_64 par exemple) s'appelle PatternPlayer_debian_Rtaudio et non pas picoloop ?
et je n'arrive à le lancer que si je n'ai aucun autre logiciel qui utilise l'audio en même temps (je dois quitter mon navigateur par exemple), ça me dit sinon :
terminate called after throwing an instance of 'RtError'
what(): RtApiAlsa::probeDeviceOpen: pcm device (hw:1,0) won't open for output.
Abandon
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 4.
Salut Zurvan,
tout d'abord merci pour ces retours qui sont top et me donne de bonnes pistes pour Arm et d'autre plateforme autre que ma debian custom et ma centos custom.
Sur raspberry, concernant la première erreur lié à '-std=c++11', je ne connais pas la plateforme raspberry. tu as probablement raison, il y a un requirement sur un g++ récent, que je trouve dommage…
En gros, le moteur helm utilise certaine "chose" qui sont lié à c++11, j'ai utilisé ce flag par défaut depuis et ça invalide ton compilateur, alors que 99% du code n'a pas besoin de ce flag… ce qui est vraiment pas terrible…
La à chaud je dirais que sans un patch pour dégager helm, où utiliser un compilateur plus récent, je ne vois pas.
Je vais donc m'acheter un raspberry pour supporter cette plateforme. Je te remercie pour ce retour. En gros si tu supprime le -std=c++11, tu vas aller pluss loin, mais tu n'auras pas de binaire…
Concernant la seconde erreur. Tu ne peux pas lancer picoloop et un nvigateur web. je pense comprendre et si c'est le cas je vais l'ajouter au README, ou tout simplement update le makefile.RtAudio, en conséquence.
RtAudio a été compilé sur ta plateforme pour Alsa.
Si tu regarde le Makefile.RtAudio tu va trouver un -D_LINUX_ALSA_ dedans.
Ce flag permet à RtAudio d'embarquer le code et l'api Alsa.
il faut dans ton cas le remplacer par -D_LINUX_PULSE, et ça supportera le pluseaudio qui doit probablement tourner en tant que process et utiliser l'api Alsa.
Si tu peux faire un double test et mettre les deux -DLINUX_ALSA_ D_LINUX_PULSE_ dans le Makefile.RtAudio, ça me permettra d'être certain qu'on peut activer plusieurs API. Et si ça fonctionne, j'ajoute les deux dans la compilation. Et oui, les autotools font ce boulot mais la il n'y en a pas…
Pour le troisième point, pourquoi le binaire ne s'appel pas Picoloop, mais PatternPlayer. C'est une longue histoire, mais c'est simple. Le fichier .cpp s'appel PatternPlayer, et j'aurais tout simplement du faire le renommage… C'est tellement simple que je ne comprend pas pourquoi je ne l'ai pas effectué plus tôt.
En tout cas un grand merci, et tiens moi au courant pour les flags de compilation de RtAudio. Il n'y a aucune raison de ne pas pouvoir d'utiliser Picoloop et un navigateur web. C'est un bug qui devrait être simple à corriger.
[^] # Re: Quelques réflexions
Posté par zurvan . Évalué à 3.
ok, merci des explications. Je me m'y connaît pas trop en programmation mais j'ai quelques notions.
ne t'inquiète pas, de toute façon j'ai vu ensuite que Raspian (la distribution debian du raspberry pi), permet d'installer g++ 4.7 et 4.8, ce que j'ai fait. Hier soir ça bloquait encore parce que j'avais fait un simple alias de g++ vers g++ 4.7, ça retourne bien g++ 4.7 dans le shell mais ça ne doit pas être pris en compte lors de la compilation depuis le script. En fait /usr/bin/g++ est un simple lien symbolique vers le binaire /usr/bin/g++-4.6 donc j'ai modifié le lien vers le binaire souhaité, et ai pu terminer la compilation ce matin (ça a été long, plus d'une heure, c'est un pi b+, sur un pi 2 avec plus de ram ça devrait aller mieux).
bonne idée, c'est un appareil intéressant et bien utile…
Je vais essayer le binaire généré ce soir, histoire de voir et surtout d'entendre si c'est utilise ou pas depuis un raspberry pi.
En attendant, voici ma version compilée :
(je ne sais pas ce qui est forcément nécessaire, donc j'ai laissé tout en vrac depuis mon dossier de compilation)
http://dl.free.fr/o2pej5YUS (35 Mo)
Si vous préférez, j'ai retiré tous les sous-dossiers et "strippé" le binaire, ça réduit la taille, mais je ne sais pas s'il a besoin de ces dépendances ou pas :
http://dl.free.fr/jcLTuTY5z (5 mo)
j'essaye de ne pas utiliser pulseaudio, mais en tout cas sur un ordinateur avec pulseaudio d'installé ça faisait la même chose. Je vais essayer de mettre les 2 options. En tout cas même sans pulseaudio, il est possible d'avoir plusieurs logiciels qui font de l'audio en même temps en général.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 2.
Je suis super content de voir que tu es arrivé à faire un binaire raspberry.
Ça me fais super plaisir, mais vraiment.
A mon avis, picosynth, picodrum, pbsynth et OPL tourneront à merveille dessus.
Le raspberry doit avoir une puissance suffisante pour les faire fonctionner.
Les autres synthés vont le mettre à genou et il est possible que tu sente un freeze dans le son une fois que tu va triggé une note qui sera envoyé à un autre moteur de synthése : open303, cursynth, helm et mda.
J'ai un ami qui va me prêter un raspberry pi B 512MiB, je vais donc pouvoir faire des tests également et mettre en place les scripts pour faire la compilation également.
Je pense qu'au final, je placerai un patch pour prendre en compte uniquement ces 4 moteurs de synthése sur le PI B.
En tout cas, un grand merci et félicitation.
[^] # Re: Quelques réflexions
Posté par zurvan . Évalué à 2.
et bien tant mieux… :)
Et tu peux être content, parce que sur un raspberry pi 2, avec 1 go de RAM, et un peu overclocké, ça tourne très bien du peu que j'ai vu (la version strippé suffit, en fait le binaire suffit + font.bmp + font.ttf) :
https://lut.im/DQ0LBa5bTe/YWEGGiAmIjs1WpWo.jpg
et le son semble bien passer, pas de latence ou de coupure, mais j'ai essayé seulement très peu de temps, je ne connais pas assez picoloop pour le pousser dans ses retranchements.
Sur l'autre raspberry pi (v1, b+, avec 512 mo de ram, celui que j'ai utilisé pour la compilation), c'était beaucoup plus lent, je n'avais pas le son (je l'ai lancé depuis vnc), mais rien que de modifier les paramètres était lent, et ce n'était pas lié à l'affichage déporté, et ça prenait 100% du CPU donc le son devait être sans doute mauvais.
Quelques réflexions supplémentaires :
- sur PC la touche ESC est loin des autres touches de modification (ctrl, alt), du coup c'est un peu fastidieux pour changer de paramètres. Un petit fichier de conf pour choisir ses touches serait top.
- avoir des touches supplémentaires de raccourci pour la version PC serait pratique également (pour aller directement dans le menu), mais ça s'éloignerait un peu de la philosophie de nanoloop.
- En parlant de nanoloop, tu m'as dit utiliser la version 2.7, c'est sur GBA ? Parce que la dernière sur gameboy c'est la 1.7 (différente version), par contre tes raccourcis de base semblent ne se caler ni sur l'une, ni sur l'autre :
http://www.nanoloop.com/two/nanoloop27.html
A cut / paste note
B + ▲/▼/◀/► edit note
- renommer la fenêtre du programme ("picoloop" au lieu de "fenêtre sans nom") serait mieux.
- dans le dossier de travail (dossier courant de picoloop), il y a un fichier audioout qui se crée, et qui grossit rapidement au fur et à mesure que picoloop fonctionne. Pourquoi pas, mais si je laisse le logiciel en plan pendant que je fais autre chose ailleurs, ça va vite saturer le disque (bon, pas tout de suite, mais au bout d'une ou deux heures….). Il y a une protection contre ça (genre au bout de 500 Mo ça réefface le début du fichier) ? Et comme j'utilise picoloop dans un dossier synchronisé entre diverses machines par owncloud, ça va vite poser problème. Mais comme je suis un petit futé, j'ai fait un
ln -s /tmp/audioout audioout
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 2. Dernière modification le 13 mai 2016 à 15:17.
Cool, j'aurais pas pensé que le raspberry pi2 pourrait suffire.
Tu as raison, pour les touches… Actuellement, Il faut recompiler pour changer les touches.
C'est définit dans Master.h, mais ça nécessite, une recompilation.
J'ai ouvert un issue dans github la dessus : "Configuration file for keyboard on pc #3"
L'écriture du fichier audioout, c'est lié à ce flags de compilation : "-DDUMP_AUDIO=1 ".
Ça se trouve dans "Makefile.PatternPlayer_debian_RtAudio", je l'utilisais pour visualiser facilement le fichier audio en sortie. Je désactive ce flage qui sert à rien.
En clair avec aplay, tu peux lire ce fichier.
J'utilise nanoloop 2.7 sur gba, j'ai aussi la version gameboy la 1.7.
J'ai cru que j'avais bien mis à jour le README, mais je me suis peut être trompé…
Nouvelle issue dans github :
Picoloop title instead of "SDL Apps" on a desktop PC
Merci pour tes retours qui sont brillants :)
[^] # Re: Quelques réflexions
Posté par zurvan . Évalué à 3.
dans Makefile.RtAudio_debian
j'ai modifié la 3ème ligne pour avoir :
CFLAGS=-O3 -Wall -I.. -DHAVE_GETTIMEOFDAY -D_LINUX_ALSA_ -D_LINUX_PULSE_
mais à la fin j'ai une erreur de compilation :
Je n'ai pas pulseaudio d'installé mais libpulse0 et libpulse-dev le sont. J'essayerai ce soir depuis un autre ordinateur…
D'autre part, à la première passe de compilation (quelque soit l'ordinateur), j'ai ce type d'erreur :
Ensuite, une fois les dossiers / fichiers générés, ça compile si j'essaye une nouvelle fois.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques réflexions
Posté par yoyz . Évalué à 2. Dernière modification le 13 mai 2016 à 14:49.
Je vais creuser la question.
Une personne a ouvert un issue la dessus hier : "Can't build on archlinux #2"
Et c'est en gros le même problème que tu rencontre.
Il faut que je rende ça plus propre.
Car actuellement c'est pas propre, c'est juste fonctionnel.
Le coup de la première compilation passe pas mais si tu relance ça fonctionne après…
Ca me plait pas bien…
L'idée de ces makefile par cible et répertoire, c'est d'avoir un répertoire par cible : debian, raspberry, windows dingoo, psp.
Et ainsi pouvoir cross compilé facilement et compiler si ça fonctionne également sur une autre cible.
J'ai pas trouvé mieux, mais c'est pas encore très sec…
[^] # Re: Quelques réflexions
Posté par zurvan . Évalué à 3.
j'ai testé avec l'émulateur (libre) ppsspp, ça fonctionne, mais le son n'est pas excellent, il y a parfois des coupures et des craquements (liés à l'émulation) :
https://lut.im/RWnj8RX2TN/B2cbCu1UxjOBJuN4.png
Prochaine étape, essayer picoloop directement depuis la distribution linux installée sur mon téléphone… mais ça va être plus compliqué au niveau du clavier, qui prend trop de place.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# coquille
Posté par Jiel (site web personnel) . Évalué à 3.
Une coquille s'est glissée dans le nom du 4e lien, c'est évidemment README.
[^] # Re: coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Corrigé, merci.
[^] # Re: coquille
Posté par Jiel (site web personnel) . Évalué à 3.
Merci à toi !
[^] # Re: coquille
Posté par zurvan . Évalué à 5.
à corriger également, les 3 "Exemple de production mu*sc*iale"
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Corrigé, merci.
# Chouette !
Posté par Olivier HUMBERT (site web personnel) . Évalué à 5.
Bravo à toi !
N'hésite pas à venir nous en parler sur linuxmao, j'en connais là bas que ça pourrait intéresser.
https://librazik.tuxfamily.org - http://linuxmao.org - https://liberapay.com/trebmuh
[^] # Re: Chouette !
Posté par yoyz . Évalué à 3.
Il faut que je passe vous voir pour en discuter. En effet linuxmao me semble être un endroit bien adapté à ce type de sujet :)
# Génial mais.
Posté par B. franck . Évalué à 0.
Super, juste ce que je cherche, et comment fait-on pour modifier, rentrer une note ?
(j'ai peut-être lu trop vite le README mais je n'ai pas trouvé l'info; et bien sûr je ne connais ni Nanoloop, ni Elektron).
[^] # Re: Génial mais.
Posté par yoyz . Évalué à 2.
Je ne sais pas quel version tu utilise, si c'est sur linux, windows ou autre.
je vais dire que c'est linux ou windows qui sont pareil pour l'interface graphique et clavier.
Les touches sont :
- haut bas gauche droite
- a, b, start, select, L, R
Sur PC elles correspondent à
- haut bas gauche droite
- lalt, lctrl, enter, esc, basckpace, tab
Plus tard, je mettrai un fichier de conf pour modifier ces touches qui sont les touches de la dingoo et psp. pour l'instant il faut modifier Master.h pour les changer.
Donc, entré une note, quand on lance le programme, c'est une fois 'lalt', afin de rentrer dans un mode d'edition ( on selectionne un menu ).
quand tu rentre dans un menu, le menu disparait.
Ca te fais entré dans le mode [env] de la machine Picosynth.
Quand tu vois un [ENV], c'est que tu es sur [ENV], sinon je dis [NOTE], [OSC], etc.
Puis une fois dans le menu [ENV] tu appuie sur 'lctrl' et la note apparait.
Tu rappuie une fois ça la coupe dans le presse papier, tu rappuie une fois ça la colle du presse papier.
Pour la modifier, 'lalt' avec haut ou bas ou gauche ou droite.
A ce moment là ca, modifie les paramètre de l'enveloppe d'amplification de picosynth. les paramètre attack/Release.
A ce moment la appui plusieurs fois sur la touche echap. Ça sort du menu [ENV], et tu verra les deux menu s'afficher.
Tu peux te ballader dedans avec gauche et droite.
Si tu arrive à trouver [MAC] tu va pouvoir changer de moteur sonore.
Positionne toi sur[MAC] et appuie sur lalt.
Une fois dedans, tu change le moteur en appuyant sur lalt avec haut, ou lalt avec bas ça fera défiler les différents moteurs sonore.
Ensuite, lis le README et pose moi des questions si il te manque des infos.
```
[^] # Re: Génial mais.
Posté par yoyz . Évalué à 2.
Si le README et mes explications ne sont pas suffisament clair.
Ouvre cette page : http://www.nanoloop.com/two/nanoloop27.html
C'est le lien vers la documentation de nanoloop.
Ca décrit la plus part des fonctionnalité.
Les deux programmes sont très proches, mais certaines choses seront valable sur Nanoloop, d'autre sur Picoloop.
Il y a peu de touche, donc tu va vite comprendre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.