Chronotensity slows down unexpectedly
Closed this issue · 7 comments
Describe the bug in detail:
When driving something with Chronotensity and I have it in a state where it should be driven continuously, it does not keep the same intensity but slows down
Expected behavior:
I would expect chronotensity to be driven continuously at same intensity with same input
Depending on the chronotensity mode, some will only proceed with variations in amplitude, to give a sort of "beat detection" feel.
I would have hoped for a way to have the chronotensity increase as a linear function of current band intensity and I don't see a way of doing so?
Here is a little visualization of all the chronotensity modes: https://streamable.com/7t27xr
Isn't the first row basically what you need? If the band has some intensity it moves forwards, otherwise it doesn't. If you need some continuous motion on top you can just get one of the millisecond timestamps from AudioLink as well and just add them together before doing the modulo.
For reference, the code is as-follows:
float DifferentialValue = ComparingValue - FilteredAudioLinkValue;
float ValueDiff;
int mode = ( coordinateLocal.x - 16 ) / 2;
// Chronotensity is organized in a (4x2)x4 grid of accumulated values.
// Y is which band we are using. X is as follows:
//
// x = 0, 1: Accumulates as a function of intensity of band.
// The louder the band, the quicker the function increments.
// x = 0: Difference between base and heavily filtered.
// x = 1: Difference between slightly filtered and heavily filtered.
//
// x = 2, 3: Goes positive when band is higher, negative when lower.
// x = 2: Difference between base and heavily filtered.
// x = 3: Difference between slightly filtered and heavily filtered.
//
// x = 4, 5: Increments when respective filtered value is 0 or negative.
// x = 4: Difference between base and heavily filtered.
// x = 5: Difference between slightly filtered and heavily filtered.
//
// x = 6: Unfiltered, increments when band is above 0.05 threshold.
// x = 7: Unfiltered, increments when band is below 0.05 threshold.
if( mode == 0 )
{
ValueDiff = max( DifferentialValue, 0 );
}
else if( mode == 1 )
{
ValueDiff = DifferentialValue;
}
else if( mode == 2 )
{
ValueDiff = max( -DifferentialValue, 0 );
}
else
{
if( coordinateLocal.x & 1 )
ValueDiff = max((-(AudioLinkGetSelfPixelData(ALPASS_AUDIOLINK + uint2( 0, coordinateLocal.y ) ) - 0.05 )), 0 )*2;
else
ValueDiff = max(((AudioLinkGetSelfPixelData(ALPASS_AUDIOLINK + uint2( 0, coordinateLocal.y ) ) - 0.05 )), 0 )*.5;
}
Here is a little visualization of all the chronotensity modes: https://streamable.com/7t27xr
Isn't the first row basically what you need? If the band has some intensity it moves forwards, otherwise it doesn't. If you need some continuous motion on top you can just get one of the millisecond timestamps from AudioLink as well and just add them together before doing the modulo.
The problem with using the first row as a driver for chronotensity is that it will be fast at the beginning but slow down more and more. Adding one of the millisecond timestamps from AudioLink would not solve this as I do not want motion if there is no action.
Here is an example I can provide: https://streamable.com/mw100v
If you take a look at the progress at 0:05 you can see that at first chronotensity progresses a lot but it slows down rapidly.
I guess this occurs because when the bass first hits the FilteredAudioLinkValue hasn't quite caught up yet?
I think this would be solved if there was a option to add the current intensity of a band as a value directly to chronotensity instead since then the progression would be linear?
Isn't the 4th category (mode == 3) what you're after? It does not look at relative shifts.
Side-note. I can understand there being some more value in proportional, non-differential values.
Closed due to inactivity.