Tweener
@alphamoonbase
If a fade has an ID, is there a way to query the remaining time of a fade?
And 2 RFEs:
1:
It would be great if we could specify the mode via the build in ParMode.CONSTANT or ParMode.EXPRESSION objects.
CreateFade(targetpar, endvalue, time, mode = ParMode.EXPRESSION, expression = sourcepar.expr)
CreateFade(targetpar, endvalue, time, mode = sourcepar.mode, expression = sourcepar.expr)
2:
Support for startvalue, so we can skip prepending a tween with targetpar.val = startvalue. Would make my scripts much more readable
CreateFade(targetpar, startvalue, endvalue, time) ```Hoi achim.
Thanks for the Feedback.
You can acces the fades member of the tweener. Its a dictionary containing dictionaries of tweens (fades). The stepsTaken entry gives you the time in ms, and timems the target time in ms.
This will be in the current next version im working on.
Using strings led to some problems in the 2022 release as == check against a string does no longer work (it worked for a while/was the only way).
Hmmm, tbh not sure about that. I might add it as a optional keyword but def not as a positional argument as this will make alot of other code much harder to read, which uses the tweener to fade from current state to new state (without having to pass the current state).
will check the fades member. thanks!
Is the github version in a working state?
Using strings led to some problems in the 2022 release as == check against a string does no longer work (it worked for a while/was the only way).
Does this mean using the tox from the community will have issues in 2022 releases? Could you please tell me which ones to expect?
Re: the start value I fully agree. In case you add it, it should be an optional keyword.
More or less. It is still in development but every core functionality is working. Be wary though that it is slower then the current one as I am experimenting with a more OOP-approach contrary to the current generative approach.
The current tweener from the community-edition is still working fine. I think the issue with the string comparison was something that hit me during development, but I might have gotten this wrong from memory (has been a while since I worked on it.)
I will just have to make sure that I do not break any depending projects (esp TauCeti) when changing arguments.
I will clean up the current community edition and see if I can implement them.
In the meantime, what you can do for ParModes is that you can use sourcepar.mode.name instead of simply passing the par mode.
thank you for the clarification. I’ll stick with the community edition
sourcepar.mode.name
very nice trick!
One last question. How do I specify custom curves? There is a note in the curves COMP about tagging CHOPs, but I can’t get it to work
Good catch. Simply connect the custom-curve to the mergeCHOP and pass the name of the curve-channel as a string-argument. Sorry for the oversight here.
yeah, that’s working. But it would be cool if there would be a way to add custom curves without modifying the inside of your component.
May I suggest a top level CHOP parameter that is referenced in a select CHOP inside the curves COMP and piped into the merge?
Good suggestion and actually already implemented on the version on github.
I also implemented the ParMode.
Will just have to make it a little faster and then I can release it.