filmov
tv
Code Review: Automixer
Показать описание
Code:
———
Related videos:
———
Since recording this video, I made a couple changes to the code which you may find in the following version:
1. While explaining the loop that does the priorities and the strength, I realized that the priorities might send the gain above 1, at which point the strength function is unspecified. To fix this, I split the loop in two and normalize the gains after dealing with priorities but before doing the strength. The procedure is the same as everywhere else: add the gains and divide each gain by the sum.
2. While recording I realized (and talked about) the super-advanced feature of multiple Automixers for video. I implemented this by adding a hidden parameter to set the instance identifier, which is then used as the address into gmem. I added a parameter to the Video processor to match. Of course, the default value for these parameters is 0, so if the user doesn’t play with the parameter, the behavior stays the same.
———
Something I forgot to explain:
In the video I mentioned that we use local variables when computing values, and only when we’re done do we assign them to positions in memory. For example, we compute ‘track_gain = …’, and then assign to ‘tracks_gains[track] = track_gain’. I justified this by saying that there may be recursive dependencies between these variables.
There’s yet another reason to do things this way: The @sample part of the code (which is writing to the memory) and the @gfx part of the code (which is reading from the memory) run in parallel. If we keep writing to memory again and again while computing values, then @gfx sometimes picks up the changes in the middle of the computation and the result is a visual glitch.
That’s also a reason to compute everything in @sample, even things that at first sight may seem better to compute in @gfx, for example, tracks_rmss_gained. The issue is that if @gfx did something like ‘tracks_rmss[track] * tracks_gains[track]’ then tracks_rmss[track] may have already been updated and while tracks_gains[track] has not. This also results in visual glitches.
Moral of the story: Only write final values to shared memory to avoid visual glitches.
———
References:
JSFX:
Sigmoid function for Strength:
Versioning:
The timing issue that this version doesn’t have but the original Automixer has (and which I think would be impossible to hear):
Video processor:
The following effects that come with REAPER:
Video processor preset: Decorative Oscilloscope with Blitter (requires JSFX video sample peeker)
JSFX: JS: video sample peeker
ReaScript:
———
Check out the Truncate silence script, a great companion for the Automixer:
———
0:00:00 - Introduction
0:01:39 - JSFX
1:22:34 - Video processor
1:27:00 - ReaScript
1:37:46 - Conclusion
———
Related videos:
———
Since recording this video, I made a couple changes to the code which you may find in the following version:
1. While explaining the loop that does the priorities and the strength, I realized that the priorities might send the gain above 1, at which point the strength function is unspecified. To fix this, I split the loop in two and normalize the gains after dealing with priorities but before doing the strength. The procedure is the same as everywhere else: add the gains and divide each gain by the sum.
2. While recording I realized (and talked about) the super-advanced feature of multiple Automixers for video. I implemented this by adding a hidden parameter to set the instance identifier, which is then used as the address into gmem. I added a parameter to the Video processor to match. Of course, the default value for these parameters is 0, so if the user doesn’t play with the parameter, the behavior stays the same.
———
Something I forgot to explain:
In the video I mentioned that we use local variables when computing values, and only when we’re done do we assign them to positions in memory. For example, we compute ‘track_gain = …’, and then assign to ‘tracks_gains[track] = track_gain’. I justified this by saying that there may be recursive dependencies between these variables.
There’s yet another reason to do things this way: The @sample part of the code (which is writing to the memory) and the @gfx part of the code (which is reading from the memory) run in parallel. If we keep writing to memory again and again while computing values, then @gfx sometimes picks up the changes in the middle of the computation and the result is a visual glitch.
That’s also a reason to compute everything in @sample, even things that at first sight may seem better to compute in @gfx, for example, tracks_rmss_gained. The issue is that if @gfx did something like ‘tracks_rmss[track] * tracks_gains[track]’ then tracks_rmss[track] may have already been updated and while tracks_gains[track] has not. This also results in visual glitches.
Moral of the story: Only write final values to shared memory to avoid visual glitches.
———
References:
JSFX:
Sigmoid function for Strength:
Versioning:
The timing issue that this version doesn’t have but the original Automixer has (and which I think would be impossible to hear):
Video processor:
The following effects that come with REAPER:
Video processor preset: Decorative Oscilloscope with Blitter (requires JSFX video sample peeker)
JSFX: JS: video sample peeker
ReaScript:
———
Check out the Truncate silence script, a great companion for the Automixer:
———
0:00:00 - Introduction
0:01:39 - JSFX
1:22:34 - Video processor
1:27:00 - ReaScript
1:37:46 - Conclusion
Комментарии