ajout de trajectoires des clouds about frontieres HOT 54 OPEN

Non il n'existe pas actuellement de canal ou de forum mis en place qui soit dédié à Frontières lui-même. (je suppose que c'est de ça que tu veux parler)
Il y a parfois quelques échanges sur l'IRC de linuxmao.

from frontieres.

merci pour ton accueil @trebmuh je suis heureux de pouvoir participer à ce beau projet !

from frontieres.

tout est ok de mon coté, je suis en train de pofiner la gestion des sauvegardes, des valeurs par defaut et des valeurs mini et maxi.
je pense aussi du coup supprimer la trajectoire bouncing dont le cas est maintenant couvert par circular en mettant le strech au maximum.
j'ai crée un nouveau type de trajectoire aussi que je suis en train de debugger : hypotrochoide
des que tout ça roule, je mets un pr

from frontieres.

en voilà une bonne nouvelle, du renfort !
bienvenue sur ce projet
et une fonction que j'espérais depuis longtemps, sans vraiment imaginer comment l'implementer.

from frontieres.

ça me fait plaisir, merci !
Je suis content de voir que l'idée te plait et que tu l'as eu aussi !
J'essaie d'uploader mon code mais j'ai bien du mal à me servir de github .. je cherche encore comment faire en espérant l'avoir uploadé d'ici ce soir.

from frontieres.

voila j'ai finis par y arriver même si je ne suis pas 100 pourcent certain de ce que j'ai fait .
Je vous laisse essayer si vous en avez envie , n'hésitez pas à me faire un retour !

from frontieres.

Salut @stilnat, et merci à toi de venir apporter ta contribution. Sois le bienvenu !
Peux-tu faire un "pull request" de ta branche de travail ? je présume qu'il s'agit de "addmove". Cela nous aide à examiner et à commenter ton travail.
(le bouton "pull request" qui est accessible sur la site web github)

from frontieres.

Salut @jpcima merci pour l'accueil ! j'ai fait le pull request correctement je crois, je te laisse me dire.

from frontieres.

@jpcima j'ai fait un nouveau pull request

from frontieres.

@jpcima @olof29 je me demandais aussi si sur github il y a un espace de discussion plus général que les issues pour discuter entre participants d'un projet.

from frontieres.

Bonjour @stilnat et bienvenue à toi. Et merci pour cette première contribution, l'idée est vraiment chouette, bravo.
Pour discuter en direct, il y a le tchat IRC de #linumao sur le réseau freenode comme l'as mentionné jp (ou bien en utilisant le webchat, si tu n'as pas envie d'utiliser un logiciel dédié à l'IRC). Et pour discuter pas-en-direct, il y a soit ici pour le côté "code", soit dans la section "développer une application" du forum de linuxmao.org ou tu pourras probablement échanger avec des utilisateurs.

from frontieres.

comment définis/choisis/edites tu une trajectoire ?

from frontieres.

@olof29 pour l'instant je n'ai définis qu'un seul type de trajectoire modifiable uniquement dans le code source à la fonction : void MyGLScreen::keyAction_Trajectory() . Il y aurait pleins de manière différentes d'éditer une trajectoire, mais il est certains que pour l'ergonomie il faudra le faire graphiquement pour les trajectoires un peu plus complexes. Par exemple pour une trajectoire circulaire il serait bien de pouvoir définir graphiquement le centre de rotation ainsi que de pouvoir le déplacer comme les autres objets de la scène. On pourrait créer une nouvelle classe "point d'ancrage" (avec un meilleur nom ^^) pour que ces points particuliers soient des objets à part entières. Les courbes de béziers par exemple ont besoin de points particulier et c'est très intuitif de les bouger graphiquement pour changer la forme de la courbe. Dans un premier temps on peut faire ça dans une fenêtre comme pour le reste des paramètres .

from frontieres.

• ajout d'une trajectoire circulaire
• calcul en temps différentiel
• vitesse en hertz

commit : 4385e4d

prochaine étape : sauvegarder l'état des trajectoires.

from frontieres.

tu peux m'expliquer comment mettre les trajectoires en oeuvre ?
je peux me pencher sur l'édition des paramètres si je sais comment.

from frontieres.

from frontieres.

@olof29 j'imagine que tu veux savoir comment faire dans le code, dans MyGLScreen::keyAction_Trajectory(int dir) ,
il y a ces lignes qui permettent un choix circulaire entre les trajectoires :

if( selectedCloud->view->getTrajectory()==nullptr){
tr=new Bouncing(100,0.2,selectedCloud->view->getX(),selectedCloud->view->getY());
}
else if(selectedCloud->view->getTrajectory()->getType()==1){
tr=new Circular(0.2,selectedCloud->view->getX(),selectedCloud->view->getY(),200);
}
else if(selectedCloud->view->getTrajectory()->getType()==2){
tr=new Bouncing(100,0.2,selectedCloud->view->getX(),selectedCloud->view->getY());
}
tu as ici les deux types de trajectoire que j'ai implémenté.
Est ce que ça réponds à ta question ? Si tu veux plus de précisions hésite pas

from frontieres.

pour le moment les paramètres sont hard codés, il n'y a pas d'autre moyen que modifier le code source à cet endroit,pour les changer. Mais pour tous les paramètres les deux classes ont des méthodes set . elles ont aussi une méthode start , stop et set trajectory . j'ai pas eu le temps de m'y repencher mais j'avais un petit soucis pour enlever toute trajectoire à un cloudvis . ha oui d'ailleurs c'est la classe Cloudvis qui contient un pointeur de type trajectoire .

from frontieres.

je vais tester un peu
ce que j'aimerais savoir, notament , c'est le mode de fonctionnement de la trajectoire, et particulierement l'interaction avec les parametres qui existaient avant, comme le x et le y.

• la trajectoire modifie t'elle ces parametres, et si oui, qu'advient il si on change manuelllement un de ces parametres alors qu'on est en cours d'une trajectoire ?
• cela modifie t'il le point de départ de la trajectoire, ou son centre, ou le point ou elle en est arrivé ?

from frontieres.

les seuls paramètres préexistant que modifie la trajectoire sont les coordonnées de visCloud x et y.
Si tu cliques sur un cloud pendant qu'il se déplace, le calcul de la trajectoire se met en pause et le déplacement manuel prend le relais tant que le cloud est sélectionné . Quand tu déplaces manuellement le cloud et qu'il a une trajectoire, le point d'origine de la trajectoire est translaté.
Si tu déselectionne le cloud la trajectoire reprends la ou elle en était . En gros tu peut modifier x et y sans crainte de casser la trajectoire, elle sera simplement translaté.

from frontieres.

pour les paramètres à modifier de la trajectoire, il y a la vitesse (speed ) qui est en hertz pour toute les trajectoires périodiques (pour l'instant on se contente de trajectoire périodique) . spécifiquement pour Bouncing il y a "bouncewidth" qui correspond au nombre de pixels que parcours le cloud en partant de l'origine en allant à gauche ou à droite, et pour Circular il y a radius qui correspond à la distance au point d'origine de la trajectoire. pour Circular mieux vaut ignorer les centerOriginX et centerOriginY (j'ai pas le code sous les yeux mais je crois qu'ils s'appellent comme ça ) pour l'instant ils sont pas utiles.

from frontieres.

donc si je comprends bien, boucing est un mouvement d'aller retour vers la droite ou la gauche ?
(il n'y a pas d'equivalent vers le haut et le bas, ou de combinaison des deux ?)
et circular fait un cercle dans le sens des aiguilles d'une montre seulement, ou un parametre négatif va dans le sens inverse ?

from frontieres.

d'autre part, tu dis que la sélection d'un cloud fait interrompre la trajectoire, mais il n'est pas nécessaire que le cloud soit sélectionné pour intervenir sur ses paramètres : une fenêtre de paramêtres peut être affichée, puis un autre cloud sélectionné, et les paramètres du premier cloud sont toujours modifiables dans sa fenêtre de parametres sans que celui ci soit sélectionné.
que se passe t'il alors ?
de plus les paramètres d'un cloud sont modifiables aussi via osc sans que celui ci soit sélectionné.
que se passe t'il alors ?

from frontieres.

bouncing part de son point d'origine , mettons que bouncewidth = 100 , alors il va 100 pixel à droite puis 100 pixel à gauche .
Pour le moment c'est son seul paramètre avec la vitesse mais je comptais en rajouter pour justement la verticale ou des mouvement sinusoidaux . Pour le cercle , passer une vitesse négative , tu peut essayer, normalement ça devrait bien partir dans l'autre sens

from frontieres.

"il n'est pas nécessaire que le cloud soit sélectionné pour intervenir sur ses paramètres"

dans ce cas je ne sais pas trop .. mais le programme ne se fait qu'en une seule thread non ? Si c'est le cas il n'y aura pas de tentative d'accéder à une variable en simultané . ça devrait marcher aussi même si ça mérite d'être testé .

from frontieres.

ha quoi que ... je crois que la mise à jour de la position par la trajectoire ne se fait que si le cloud est sélectionné . On va avoir un souci c'est que le point d'origine de la trajectoire ne sera pas modifié si on déplace le cloud sans qu'il soit sélectionné . Il faudrait donc une variable isModified qui vérifie si le cloud a bougé entre deux appels de fonctions, et qui modifie le point d'origine de la trajectoire en conséquence si c'est le cas

from frontieres.

C'est un bon point tu as bien fait de me le faire remarquer , je vais essayer de régler ca ce soir .

from frontieres.

Il faudrait donc une variable isModified qui vérifie si le cloud a bougé entre deux appels de fonctions

il en existe une afin de gerer les mises a jour de la fenetre de parametres :
changed_gcX
changed_gcY

mise à jour lorsqu'un parametre x ou y de cloudvis est changé.

je ne suis pas sur qu'elle soit utilisable dans les deux situations car une fois utilisée, elle est réinitialisée, donc la premiere fonction à l'utiliser va la rendre obsolete pour l'autre... mais il est possible de s'en inspirer.

from frontieres.

je pense en outre que limiter le suivi de trajectoires au seul cloud sélectionné n'est pas correct :

• on peut vouloir appliquer des trajectoires à plus d'un cloud simultanément.
• la question de la polyphonie midi est à considérer sérieusement, chaque note-on devant pouvoir faire démarrer une trajectoire à son point de départ, alors que d'autres seraient en cours.
• j'en déduis que la trajectoire ne devrait pas être un parametre de cloudvis...

il m'apparait que le problème de trajectoire est beaucoup plus complexe que ça (c'est d'ailleurs pourquoi je ne m'étais pas lancé dessus pour le moment). il faut à mon avis d'abord regler les problemes de performances et de remanance du son en tranchant et en corrigeant la production sonore elle meme, car pour le moment elle calcule en fonction du visuel à chaque tour de la boucle de jeu, et c'est la source de la plupart des soucis.
j'ai vraiment le sentiment que la forme d'onde devrait être calculée indépendament de de sa lecture dans la boucle de production sonore, et que cela concerne aussi le concept de trajectoire.

mais cela me semble carrément insoluble en fait parceque trouver un point de bouclage qui permet d'avoir un échantillon sonore répétable peut s'avérér impossible si on combine trajectoire et variations de pitch qui sont susceptibles de ne générer des boucles qu'au bout d'un temps considérable ...

from frontieres.

je manque un peu de vocabulaire pour bien comprendre tes remarques :
qu'appelles tu la forme d'onde ? la rémanance du son ? point de bouclage ?

Aussi pour tes premières remarques , que veux tu dire par "limiter le suivi de trajectoires au seul cloud sélectionné" ?
Je crois que tes deux points sont possible avec le code actuel .
Il peut y avoir plusieurs trajectoires en simultané , démarrant en simultané , le code le permet en l'état . (après simultané c'est pas instantané non plus vu que le code est pas parallèle mais ca devrait être avec un décalage très négligeable )

from frontieres.

ok avais compris de travers pour la possibilité de plusieurs trajectoires simultanées.
par contre la question reste posée pour la polyphonie midi qui peut declencher plusieurs notes pour un meme cloud. à des moments différents.
une note est en cours de trajectoire, et l'autre doit la commencer sans affecter celle en cours.

• la remanance du son : c'est un phenomene que j'ai remarqué qui est à mon avis un gros bug dans la logique de production du son, il y a une issue a ce sujet.
• la question du point de bouclage :
  en l'etat du code ça n'existe pas.
  c'est une notion née de la recherche de performances sur la production sonore.
  en l'etat actuel, la boucle de production du son explore entierement l'environnement, : du cloud aux grains, aux echantillons. cela a pour effet que au dela de 3 ou 4 clous actifs (ou notes en midi), on arrive aux limites du code et on se retrouve avec des xruns (machine super otpimisée pourtant)
  je reflechis actuellement à la possibilité de s'y prendre autrement, et de calculer à l'avance un echantillon sonore qui serait lu dans la boucle de production.
  cela necessite de penser à un point ou cet echantillon boucle sur lui meme.
  le probleme est que cela peut amener des echantillons tres longs si la variation de pitch est tres lente. si en plus il y a des trajectoires, avant de boucler ce serait encore plus long.

from frontieres.

"cela necessite de penser à un point ou cet echantillon boucle sur lui meme."
ça veut dire quoi qui boucle sur lui même ?

"une note est en cours de trajectoire, et l'autre doit la commencer sans affecter celle en cours."
je comprends pas trop ça non plus , j'ai cru comprendre qu'un grain était posé par le cloud de façon aléatoire (selon une loi de probabilité déterminé par "windows") , puis qu'il jouait un échantillon de son déterminé par les paramètres (durée , pitch, ect ...), par sa position projeté sur le signal et sa distance . mais j'ai l'impression que le grain ne se déplace pas avec le cloud par contre , donc que les notes n'ont pas de trajectoires à proprement parler , même si la ou elles apparaissent dépendent de la trajectoire du cloud.
une note ne devrait pas affecter celle en cours il me semble mais je me suis pas penché du tout sur le midi encore cela dit .

from frontieres.

@olof29 ok j'ai compris ce que tu voulais faire pour gagner en performance et pourquoi c'était difficilement compatible avec des trajectoires. concernant la variation de pitch , est ce que c'est pas possible de l'appliquer à moindre cout , après que la boucle soit calculé ?

from frontieres.

peut être, mais je ne maitrise pas assez le sujet pour le moment pour voir comment, je suis donc limité à émettre des idées en souhaitant que quelqu'un sache le faire ou me donne suffisament de moyens pour que j'y parvienne...
mais en tout état de cause, dans sa forme actuelle, le code rend Frontières quasi inexploitable normalement en tant qu'expandeur midi et on ne peut raisonnablement pas se dire qu'il doit rester limité à un programme avec une interface géniale, mais qui n'est utile qu'en situation très limitées.
bref tout ceci pour dire qu'il serait bien de penser les trajectoires de façon à ce qu'elles ne rajoutent pas du temps de calcul dans la boucle de production, et qu'elles ne complexifient pas l'éventuel changement dans le mode de production sonore.

from frontieres.

de retour sur la fonction trajectoire, je me heurte à un petit souci :

• j'ai ajouté la visualisation du type de trajectoire à l'appui de la touche i
• je suis en train d'ajouter à la fenetre de parametres des clouds la gestion des trajectoires.
  et là je me rends compte que la trajectoire se comporte d'une manière qui ne convient pas :
  elle modifie les parametres x et y du cloudvis, et cela a pour effet de rendre impossible la modification de ceux ci manuellement par les parametres.
  de plus cela modifie la place de base du cloud si on change de type de trajectoire :
  la derniere place du cloud devient la place de base.

il faudrait donc que les parametres x et y correspondent à la place originelle du cloud et que ceux ci restent modifiables depuis la fenetre de parametres ou par communication externe, avec pour effet de modifier la place du centre du cercle pour une trajectoire circular, par exemple.

il faudrait donc que le cloudvis s'affiche à une place qui tienne compte du point de départ et du décalage produit par la trajectoire, et non à un point de base qui a été mofifié par la trajectoire.

peux tu me dire où dans le programme la trajectoire modifie la place du cloud, afin que je voie comment faire cette modif ?

peut etre serait il d'ailleurs judicieux que l'on change la visualisation du cloud en gardant quelque chose de visible au point d'origine de celui ci, qui puis permettre de sélectionner le cloud sans avoir besoin de courir apres lorsqu'il a une trajectoire.

d'autre part, je me pose une question : pourquoi arreter la trajectoire lorsque le cloud est sélectionné ?

from frontieres.

Je suis entièrement d'accord, il faut travailler avec un décalage et non en modifiant directement les coordonnées. C'est pour cela que je pense que la trajectoire ne devrait pas se préoccuper de la position de l'objet, un défaut de l'implémentation proposée (car la trajectoire contient un point origin).

Je te renseigne une fois que je me suis remis en tête le fonctionnement actuel.

from frontieres.

@olof29 la modification de la position du nuage se produit à cet endroit (updateCloudPosition avec trajectoire) :
https://github.com/stilnat/Frontieres/blob/7fc7fbdae9dabbefae1a8e81fbfa9764075d27e7/sources/visual/CloudVis.cpp#L192

from frontieres.

merci jpcima.
je pense que ce n'est pas grand chose en fait de changer la chose, il suffit d'introduire une variable decalex et decalagey qui sera utilisée pour l'affichage du cloud, et qui sera modifiée par la trajectoire et ajoutée à x et y à l'affichage
il faut aussi que le cloud affiche qquelque chose à son origine (un deuxieme cercle, plus fin par exemple), et que ce soit son emplacement qui serve à selectionner le cloud et non celui en cours de trajectoire.
je vais regarder si je peux faire ça...

from frontieres.

voilà, j'ai mis un pr qui regroupe tout ça : on voit maintenant la trajectoire à l'appuis de la touche i, on peut aussi la chosir dans la fenetre clouddialog, et en modifier les parametres, et ai rajouté un cercle au centre de la trajectoire, et c'est lui qui est selectionnable maintenant, ce qui evite de courir apres le cloud pour le selectionner

from frontieres.

Par contre à mon avis le domaine des vitesses autorisées est beaucoup trop grand.
A mon avis cela devrait se limiter à quelques dizaines de Hz et pas plus.

from frontieres.

aucun souci à changer ça, les valeurs mini et maxi sont juste à changer dans paramcloud.h (d'ailleurs à l'avenir, peut être devrions nous les mettre dans un fichier)
à quelle valeur veux tu que je la mette ?

from frontieres.

Quelque chose qui fonctionne bien en pratique.. essayer avec ±15 Hz

from frontieres.

je suis maintenant en train de chercher à regrouper en un seul type de trajectoire BOUNCING et CIRCULAR, (dans le type CIRCULAR) en introduisant 2 nouveaux parametres à la trajectoire circular :

• strech : ce parametre varie entre 0 et 1 et a pour effet d'applatir le cercle pour en faire une élipse. à 0 il n'applatit rien, on a donc un cercle, à un il applatit completement, on a donc une ligne (équivalent donc à BOUNCING, entre les deux on a des élipse plus ou moins applaties
• angle : ce paramètre que j'aimerais exprimer en degrés variant de 0 à 360 donne l'axe de l'elipse : à 0 cet axe est vertical demarrant vers le haut, à 90 horizontal demarrant vers la droite, etc...

mon problème : je cherche la formule pour calculer x et y à partir de ces paramètres, du rayon, et de la vitesse.... et je rame :)

from frontieres.

@olof29 voici un exemple que je réalise avec étirement X et Y, et rotation.
En fait je prends le vecteur comme nombre complexe, et cela permet de travailler soit dans le système polaire soit cartésien.

Le système polaire trivialise la rotation, quand à la mise de l'échelle il suffit de multiplier le facteur d'étirement par le X et/ou Y.

Uniquement à la fin, je positionne par rapport à l'origine.

pt2d Circular::computeTrajectory(double dt)
{
    double sp = this->getSpeed();
    double ph=this->getPhase();
    const double PI  =3.141592653589793238463;
    ph+=sp*dt;
    //define the phase modulo the period of the trajectory to avoid having phase going to infinity
    setPhase(ph-int(ph));

    //see Euler spiral for a smooth passage from a spiral to a circle
    if (distanceToCenter<=radius)
        distanceToCenter+=radius/150.;

    //the modulus and the angle, a polar complex number
    double rho = (distanceToCenter < radius) ? distanceToCenter : radius;
    double theta = ph * 2 * PI;

    //// Valeurs (Exemple) ////
    const double monAngle = 45. * (PI / 180.); // rotation 45°
    const double stretchX = 3.0; // étirement horizontal
    const double stretchY = 0.7; // étirement vertical
    //// Fin exemple       ////

    // convert to cartesian (real=X, imag=Y)
    std::complex<double> cartesian = std::polar(rho, theta);

    // stretch first
    cartesian = std::complex<double>(cartesian.real() * stretchX,
                                     cartesian.imag() * stretchY);

    // back to polar
    rho = std::abs(cartesian);
    theta = std::arg(cartesian);

    // then rotate, using polar coordinates
    theta += monAngle;

    // back to cartesian
    cartesian = std::polar(rho, theta);

    // add origin
    pt2d orig = getOrigin();
    return pt2d(orig.x + (float)cartesian.real(),
                orig.y + (float)cartesian.imag());
}

from frontieres.

super.
j'ai quand meme le sentiment qu'on a un parametre de trop là, non ?
on ne pourrait pas faire uniquement avec un seul etirement et l'angle ? (ou plutot compression et angle)
(au départ je pensais faire comme ça aussi, mais en fait sans l'angle, juste etirement horizontal et etirement vertical, mais ça ne me semblait pas assez clair a l'utilisation)

from frontieres.

Une possibilité, c'est de mettre un paramètre d'étirement de domaine [-x .. +x], qui affecte X lorsqu'il est en valeur négative et Y dans les positifs (ou l'inverse).

from frontieres.

ça ne me parait toujours pas clair a l'utilisation.
je peux essayer d'adapter ce que tu as mis, mais la fac de math c'etait y'a 40 ans pour moi... je suis un peu rouillé pour les complexes, j'ai jamais plu eu a les utiliser depuis :/

from frontieres.

Le contrôle dont je parle définit les 2 étirements en fonction d'une seule valeur.

Je mets une illustration. Au centre (0) il s'agit du cercle, sinon étiré en X/Y en fonction de quel côté de tournes le bouton. Ça fait une transition linéaire telle que je montre sur le dessin.

En code cela donnerait sans doute quelque chose comme ceci.

double pStretch = /* le paramètre d'étirement */; 
double stretchX = 1, stretchY = 1;
if (pStretch > 0)
    stretchY += pStretch;
else
    stretchX += -pStretch;

from frontieres.

je comprends ton propos.
mais ce n'est pas ce que je cherche à obtenir.
dans ta version, on etire le diametre dans un sens vertical ou horizontal seulement, et le diametre se retrouve à varier avec l'etirement.
ce que je cherche à faire pour ma part est d'obtenir des elipses qui peuvent aussi bien etre obliques, et donc le diametre le plus long est toujours egal au diametre du cercle.

le parametre strech variant entre 0 et 1 gerant l'applatissement de l'elipse, et le parametre angle son orientation

from frontieres.

Plus simplement, si le contrôle permettait de varier stretchY de 0 à 1, et on fige stretchX à 1 ?
cela te paraît convenable de cette manière ?
si c'est la direction Y que tu veux aplatir alors le même effet reste réalisable avec rotation 90°.

from frontieres.

je ne suis pas sur de bien comprendre, mais si tu veux dire qu'il suffit d'un seul facteur strech et de l'angle, oui

from frontieres.

Oui un seul facteur stretch.
En utilisant le facteur Y, cela donnera donc une ellipse rétrécie en hauteur, et en ce cas le côté droit pointera vers l'angle 0° ce qui me paraît le plus approprié.

from frontieres.

du moment qu'nesuite on peut l'incliner selon l'angle qu'on veut....

from frontieres.

bon, voilà l'ypotrochoide incluse, les angles gérés, ainsi qu'un nouveau parametre : progress, qui permet de gerer la vitesse à laquelle on passe de la position de base à celle de la trajectoire finale (la spirale dans la version circular.
voici les idées que je pense chercher à developper ensuite :

• trajectoire courbe de bezier
• barre de transport pour mettre en pause, (re)lancer, reinitialiser une trajectoire
• supprimer l'arret des trajectoires à la selection des clouds
• envisager des trajectoires enregistrées manuellement (avec des fichiers de trajectoires enregistrables et rechargeables)
• et le clou, une idée saugrenue qui m'est venue en observant un groupe de moucherons d'été qui voletaient en groupe : créer un gestion comportementale de groupe des trajectoires des clouds les uns par rapport aux autres (type d'evitement, d'atirances, etc...), afin de créer un tout nouveau type de décision dans la génération des sons.

from frontieres.