ajout de trajectoires des clouds #75
Comments
|
en voilà une bonne nouvelle, du renfort ! |
|
ça me fait plaisir, merci ! |
|
voila j'ai finis par y arriver même si je ne suis pas 100 pourcent certain de ce que j'ai fait . |
|
Salut @stilnat, et merci à toi de venir apporter ta contribution. Sois le bienvenu ! |
|
Salut @jpcima merci pour l'accueil ! j'ai fait le pull request correctement je crois, je te laisse me dire. |
|
@jpcima j'ai fait un nouveau pull request |
|
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) |
|
Bonjour @stilnat et bienvenue à toi. Et merci pour cette première contribution, l'idée est vraiment chouette, bravo. |
|
merci pour ton accueil @trebmuh je suis heureux de pouvoir participer à ce beau projet ! |
|
comment définis/choisis/edites tu une trajectoire ? |
|
@olof29 pour l'instant je n'ai définis qu'un seul type de trajectoire modifiable uniquement dans le code source à la fonction : |
commit : 4385e4d prochaine étape : sauvegarder l'état des trajectoires. |
|
tu peux m'expliquer comment mettre les trajectoires en oeuvre ? |
|
la je dois bouger mais je t'explique ça dans moins d'une heure. merci pour
le frontiere.pro je trouvais pas l'erreur
Le mar. 9 avr. 2019 à 09:27, Olivier Flatres <[email protected]> a
écrit :
… tu peux m'expliquer comment mettre les trajectoires en oeuvre ?
je peux me pencher sur l'édition des paramètres si je sais comment.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ANrieTjLzFlOQhQvIk2XXQWTT_TuTyaVks5vfEDKgaJpZM4cYV7v>
.
|
|
@olof29 j'imagine que tu veux savoir comment faire dans le code, dans MyGLScreen::keyAction_Trajectory(int dir) , if( selectedCloud->view->getTrajectory()==nullptr){ |
|
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 . |
|
je vais tester un peu
|
|
les seuls paramètres préexistant que modifie la trajectoire sont les coordonnées de visCloud x et y. |
|
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. |
|
donc si je comprends bien, boucing est un mouvement d'aller retour vers la droite ou la gauche ? |
|
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é. |
|
bouncing part de son point d'origine , mettons que bouncewidth = 100 , alors il va 100 pixel à droite puis 100 pixel à gauche . |
|
"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é . |
|
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 |
|
C'est un bon point tu as bien fait de me le faire remarquer , je vais essayer de régler ca ce soir . |
il en existe une afin de gerer les mises a jour de la fenetre de parametres : 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. |
|
je pense en outre que limiter le suivi de trajectoires au seul cloud sélectionné n'est pas correct :
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. 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 ... |
|
je manque un peu de vocabulaire pour bien comprendre tes remarques : Aussi pour tes premières remarques , que veux tu dire par "limiter le suivi de trajectoires au seul cloud sélectionné" ? |
|
ok avais compris de travers pour la possibilité de plusieurs trajectoires simultanées.
|
|
"cela necessite de penser à un point ou cet echantillon boucle sur lui meme." "une note est en cours de trajectoire, et l'autre doit la commencer sans affecter celle en cours." |
|
@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é ? |
|
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... |
|
de retour sur la fonction trajectoire, je me heurte à un petit souci :
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é ? |
|
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 Je te renseigne une fois que je me suis remis en tête le fonctionnement actuel. |
|
@olof29 la modification de la position du nuage se produit à cet endroit ( |
|
merci jpcima. |
|
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 |
|
Par contre à mon avis le domaine des vitesses autorisées est beaucoup trop grand. |
|
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) |
|
Quelque chose qui fonctionne bien en pratique.. essayer avec ±15 Hz |
|
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 :
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 :) |
|
@olof29 voici un exemple que je réalise avec étirement X et Y, et rotation. 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());
} |
|
super. |
|
Une possibilité, c'est de mettre un paramètre d'étirement de domaine |
|
ça ne me parait toujours pas clair a l'utilisation. |
|
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; |
|
je comprends ton propos. le parametre strech variant entre 0 et 1 gerant l'applatissement de l'elipse, et le parametre angle son orientation
|
|
Plus simplement, si le contrôle permettait de varier |
|
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 |
|
Oui un seul facteur stretch. |
|
du moment qu'nesuite on peut l'incliner selon l'angle qu'on veut.... |
|
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. |
|
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.
|
salut tout le monde,
j'adore ce projet et je suis en train de bosser sur ma premiere contribution sur github !
Je trouve qu'il serait cool qu'on ait la possibilité de définir des trajectoire pour les clouds de façon à automatiser des dynamiques dans la production du son.
J'ai un peu travaillé dessus déjà, je vais essayer de le mettre sur github .
J'ai ajouté une classe abstraite trajectory de laquelle héritera toute les autres trajectoires
une premiere classe qui implemente trajectory appellée "Bouncing"
j'ai ajouté à la classe CloudVis un pointeur de type Trajectory
j'ai ajouté une méthode permettant de créer un cloud qui bouge quand on appuie sur I (pour l'instant que d'une seule façon)
J'ai modifié la méthode Draw de Cloudvis pour qu'il prenne en compte la trajectoire si il bouge.
Plus tard, j'aimerais ajouter d'autre type de trajectoires (circulaire, b-splines, à la main), la possibilité d'activer ou désactiver le mouvement d'un cloud, la possibilité de modifier les paramètres des trajectoires dans le logiciel et peut être d'autres fonctions auquels je n'ai pas encore pensé.
N'hésitez pas à me donner des retours sur mon code, en matière de code coopératif je suis débutant je vais surement faire des erreurs, et ça fait un moment que je n'ai plus fait de C++ je ne suis plus très a l'aise avec.
The text was updated successfully, but these errors were encountered: