Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Le paramètre Speed n'a pas d'effet dans le cadre de la trajectoire Random #151

Open
Xon77 opened this issue Feb 26, 2017 · 9 comments
Open

Comments

@Xon77
Copy link

Xon77 commented Feb 26, 2017

MacOS 10.12.3
Reaper 5.32
SpatGRIS 0.113

Contrairement à la trajectoire Random Target, la vitesse de lecture de la trajectoire n'a logiquement aucun impact sur la trajectoire Random, mais pourrait agir sur les modes de mouvement (slow, mid, fast). Je le note pour amélioration, puisque la prise en compte de ce paramètre pour cette trajectoire n'est pas fondamentale.

Concernant le paramètre Speed, j'aurais aussi une interrogation :
Ce paramètre, qui s'enregistre sous le nom / SpatGris dans la piste d'automation va de -2.5 à 2.5. Je remarque cependant que la ligne d'automation n'enregistre que la partie positive. Et ce qui est surprenant, c'est qu'à la relecture, toute l'automation même en dessous de 0 est bien retranscrite. Il n'y a donc pas de problème, mais cela m'étonne un petit peu.

@Normandeau
Copy link
Member

Pour compléter la remarque de Christophe, voici à quoi ça ressemble dans Reaper:

speed spatgris reaper

Pourtant la variable a été déplacée constamment de +2,5 à -2,5! Et comme le dit Christophe: «Et pourtant elle tourne».
Elle a aussi un drôle de nom: /Spatgris: je ne suis pas certain que c'est bon.
DP et Logic
Autre remarque: cette variable ne s'enregistre pas en mode automation ni dans DP, ni dans Logic.
BTTF
Enfin, sur le plan conceptuel, elle comporte une autre erreur selon moi. En fait, elle se nomme Speed, mais elle devrait être dénommée Back to the Future, non? BTTF, ou quelque chose du genre. Puisqu'elle permet d'aller plus vite en avant ou plus vite en arrière.
Mais cela pose un problème. Car elle n'est active que lorsqu'on joue une trajectoire, modifiant de la sorte la durée et la direction de celle-ci. Or en allant dans la direction négative, autrement dit en remontant dans le temps, on devrait décaler à plus tard la fin de la trajectoire, non? Et en utilisant la direction positive, on devrait accélérer le temps et précipiter le fin de la trajectoire. Or c'est l'inverse qui se passe. Les valeurs négatives accélère la fin de la trajectoire.

Rien de mieux qu'une petite vue:

https://www.dropbox.com/s/amom2zmu26fof7o/Speed%20Manuelle.mov?dl=0

À noter cependant que lorsque la valeur est fixée à -2.500 ou à +2.500 la trajectoire se déroule à vitesse rapide. Si on a une trajectoire de 30s par exemple (comme dans le film), elle s'écrit en 4,5s, ce qui correspond à un facteur de 6.66666. Question: d'où ça vient ce facteur? Ne devrait-on pas avoir une valeur de 2,5 ici?

speed trop rapide

@theRedMercury
Copy link
Member

Je pense que le mieux serait que la vitesse ne soit pas enregistrée comme automation.

Car la vitesse change la position X et Y de la source et ces deux valeurs sont déjà enregistré comme automation.

@Xon77
Copy link
Author

Xon77 commented Feb 27, 2017

En effet, ce paramètre ne devrait pas être enregistré. Il est là seulement pour augmenter les possibilités d'écriture de l'automation d'une trajectoire en temps réel.

Juste sur le plan conceptuel :

  • le terme Speed ne me choque pas, puisqu'une vitesse de lecture négative permet de lire à l'envers...
  • comme tout changement de vitesse modifie le déroulement temporel de l'automation et peut entraîner des choses étranges... je pense que toute modification du slider de la vitesse devrait faire basculer l'écriture de l'automation dans un mode infini (jusqu'à ce l'on décide d'appuyer sur cancel) et où la barre de déroulement temporel serait désactivé.

@Normandeau
Copy link
Member

Normandeau commented Feb 27, 2017

J'ai déplacé ces deux commentaires dans la bonne issue et les ai effacés de l'issue 153 avec lesquelles ils n'avaient rien à voir:
David:
Les trajectoires fonctionnent dans Reaper si l’on change manuellement la vitesse de lecture pour qu'elle soit autre que 0. Dans Logic (version 10.3.1) toutefois, les trajectoires ne fonctionnent tout simplement plus et ce quelle que soit la vitesse de lecture.
Nicolas:
J'ai désactivé l'automation de la vitesse, donc cela ne devrait ne plus posé de problèmes pour la suite.

@Normandeau
Copy link
Member

David, que veux-tu dire par cela: «Dans Logic (version 10.3.1) toutefois, les trajectoires ne fonctionnent tout simplement plus et ce quelle que soit la vitesse de lecture.?
Aucun problème avec Logic 10.3.1 chez moi.

@led78
Copy link

led78 commented Feb 27, 2017 via email

@Normandeau
Copy link
Member

Je vois dans ton vidéo que tu utilises le mode OSC, que tu en Latch, sur une piste stéréo. Ce serait bien de décrire les conditions exactes des expériences que vous faites. Car le nerf de la guerre, il est là. Reproduire exactement une situation problématique, avec tous ses paramètres. Tous les détails sont importants car il se peut que cela soit une combinaison de choses inédites qui causent le problème.
En tout état de cause, je viens de tester à nouveau ici, mais rien à signaler, ça fonctionne..

@led78
Copy link

led78 commented Mar 10, 2017

Amélioration future: Je me questionne au sujet des termes « fast, mid, slow » pour les trajectoires Random. J'aime bien cette option, mais je m'attendais à pouvoir modifier la vitesse du jitter aléatoire, ce qui ne semble pas être le cas; la vitesse du jitter reste toujours la même, c'est plutôt l'amplitude spatial du mouvement (jitter) qui est agrandi (fast) ou rapetissé (slow). Je ne comprend pas l'emploi de termes désignant une vitesse pour modifier l'amplitude du mouvement puisque ce sont deux dimensions différentes. Ne serait-il pas mieux d'avoir ces deux paramètres contrôlés par des potentiomètres et dissociés d'un type de trajectoire en particulier? Un potentiomètre pour la vitesse de jitter et l'autre pour son amplitude (spatiale). Ces paramètres (amplitude et vitesse du jitter aléatoire) seraient donc séparés et applicables (optionnels) à tous les types de trajectoires, dont Random (obligatoire dans ce cas) et Random target. Qu'en pensez-vous?

@Xon77
Copy link
Author

Xon77 commented Mar 10, 2017

Je me suis fait la même réflexion en pensant aux trajectoires, (et notamment avec l'ellipse ou la spirale, qui vont plus ou moins rapidement en fonction de leurs positions) :

  1. la distinction entre le mouvement (forme et amplitude) et
  2. le déroulement temporel (vitesse d'exécution : stable - plus ou moins rapide ou variable selon le début ou la fin de la trajectoire)
    Juste pour mentionner une amélioration évoquée au sujet de la vitesse des trajectoires : Nouveau mode de trajectoires #30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants