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

[FEATURE] More dynamic or adjustability of the parameter azimuth #197

Open
0xBEEEF opened this issue May 27, 2021 · 4 comments
Open

[FEATURE] More dynamic or adjustability of the parameter azimuth #197

0xBEEEF opened this issue May 27, 2021 · 4 comments
Assignees
Labels
dsp enhancement New feature or request

Comments

@0xBEEEF
Copy link

0xBEEEF commented May 27, 2021

Is your feature request related to a problem? Please describe.
Since the new version 2.8.0 there is finally an azimuth parameter. This is great in principle, because it makes the simulation much more realistic.

Describe the solution you'd like
However, what is still missing is somehow a kind of dynamic setting of the value. If I currently specify a value here, then this is statically applied to the signal over the entire time. Could not notice any change, at least at first glance, when I changed other parameters. For real tape recordings, however, this is not the case. To emulate the sound of a real tape recorder, this value would also have to contain a certain dynamic. Azimuth can be very small but also large during playback - i.e. sometimes the phase shift is larger, then smaller again. I know this only too well from digitizing old recordings. There I already had the craziest discoveries depending on the tape age.

Therefore it would be desirable if the whole thing was a bit more realistic.

Additional context
Would be very happy to provide more info, but the requirement is very difficult to prove well with pictures, because it depends on the signal.

@0xBEEEF 0xBEEEF added the enhancement New feature or request label May 27, 2021
@jatinchowdhury18
Copy link
Owner

Thanks for the feature request! Definitely an interesting idea.

From my understanding of azimuth, and the way that it's currently implemented, the time alignment between the left and right channels is dependent on the azimuth angle between the tape and playhead, which should never change during playback. Although, of course in the plugin version, there's nothing to stop someone from automating the parameter so that it does change over time. The only other plugin parameter that will affect the azimuth time (mis)alignment is the tape speed.

However, what I have heard in my tape recording experience is a stereo fluctuation over time, that I believe comes from fluctuation in the "altitude" angle of the tape. The main difference being that this would change the level (and probably filtering) between the stereo channels, rather than the time alignment.

Since I have a hard time explaining the different angles, I usually think of it in the context of the aviation principle axes:
image
If I imagine a tiny plane flying down the length of the tape in the direction of the tape's movement over the playhead, the azimuth angle corresponds to the "yaw" axis, while the altitude angle corresponds to the "roll" axis.

I would love to include some sort of dynamic "altitude" angle parameter (might need a better name for it), though I haven't yet been able to characterize the way the altitude fluctuates over time on my own tape machine. Anyway, I'll have to think about it a bit more, and see what might be possible!

Thanks,
Jatin

@0xBEEEF
Copy link
Author

0xBEEEF commented May 29, 2021

First of all, great respect and thank you for the comprehensive explanations.

Sounds very conclusive in my view. But now I still have maybe a few stupid questions for which you may also have an answer.

I have used the azimuth correction of the plugin "StereoTool". You can find more info about it on this page, if you search for Azimuth. There is a display that shows the current phase and the deviations. From this it is quite clear that it is apparently not linear.

image

Your assumption is correct that the center of the azimuth is almost always at the same position, but there are always small or larger deviations.

image

Therefore, I currently assumed that the phase shift is subject to some dynamics and is not purely linear.

Perhaps that was only a wrong assumption of me, that I do not exclude now. But I have noticed a similar (not always the same) behavior with almost all tapes, and that in the identical playback device.

@jatinchowdhury18
Copy link
Owner

Ah, thanks for sharing these plots, that's very interesting! From my understanding of the "StereoTool", it's essentially "guessing" at the azimuth error based on the incoming signal, which I think is the source of the variance, even though (I believe) the underlying physical "generating process" for the azimuth error should be constant.

That said, I was thinking about it, and the best way to do this is to be scientific about it, and run an actual experiment! I'm planning to record a test signal (probably either a sine tone or a pulse train) into my tape machine, then try to manually adjust the playhead azimuth, and record the playback of the test signal, which I can then use to measure how constant the azimuth is. Unfortunately, my tape machine is broken again, so it might be a little bit until the system is stable enough that I can run an actual experiment. I'll let you know more once I'm able to take some measurements!

Thanks,
Jatin

@jatinchowdhury18 jatinchowdhury18 added this to the 2.9.0 Release milestone Jul 28, 2021
@jatinchowdhury18
Copy link
Owner

I was hoping to be able to follow up on this in time for the version 2.9.0 release, but since I haven't been able to make measurements yet, I'll push it to a later milestone. I do still want to look more closely at this idea, and see if we can get some more realistic behaviour with regards to azimuth/altitude fluctuation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dsp enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants