Macros: Change Pitch intermittently zero'd out

Audacity 2.3.0
Windows 10

I created a macro that speeds up tempo 6%, reduces pitch -5%, and normalizes. Ran it on a dozen projects, worked fine. Then checked some of them just to be sure, and found the last six the change pitch stopped being applied.

I checked the macro. As shown in the picture below, the parameter appeared to be correct. (It changes the -5 to -5.011 by itself, whether in a macro or not, so that part is fine). However, when I clicked Edit, the window that opened shows the percent change set back to 0, as shown in the picture.

I reset it to -5. The macro then ran fine, including change pitch, on several projects. Closed Audacity, reopened, and found same problem: the change pitch was not being applied, and on checking got the same result as in the picture, the parameter appeared to be fine, but on edit found it was back to zero. So changed it to -5 again, and the macro again ran fine.

Closed all Audacity projects, reopened, and same behaviour - reset back to zero.

Workaround: keeping one Audacity “Temp” project with just a label track open at all times.
Audacity-macro-bug.PNG

I think that’s because the slider covers such a large range (-99% to +400%) that the slider updates the % value to the nearest “tick” position. The % value itself is stored to much higher precision (0.001 %), so as long as you don’t open the interface, “-5.000 %” really is “-5.000 %”.

That is very strange.
Could you check the macro text file. After setting the pitch change to -5.000 you should see:

ChangePitch:Percentage="-5" SBSMS="0"

or

ChangePitch:Percentage="-5" SBSMS="1"

The change from -5 to -5.011 is not an issue.

As per the pic in my post, the macro text file has the correct setting. And on close and reopen of Audacity it has the right setting.

The issue is that, on close and reopen, it no longer gets applied. And as per the pic in my post, when you click Edit, the setting is shown as a zero “0”, even though the macro text, as shown in the pic, is -5.011.

Please you post your macro text file so that I can see if I can reproduce the problem. Thanks.

Ok, please find macro file attached. Note however the problem is not in that file, it is fine. Again, if you look at the pic I posted, it shows the macro parameters are correct, drawn from that file. The issue is that after closing and reopening Audacity, the pitch percentage parameter no longer gets passed to the Change Pitch effect.

And even more interestingly, you can watch it happen. If you click Edit on the effect from the Manage macros window, you can see the pitch percentage does not get passed to the Change Pitch effect, and the pitch percentage is zero.

This is shown very clearly in the pic I posted. I suggest starting by checking that pic out.
DPPMeffects1.txt (158 Bytes)

Yes it is, but I was having difficulty following your “steps to reproduce”, and I wanted to try and follow your steps exactly so I could see what you are seeing.

This is the key. When the Change Pitch GUI opens, it tries to get the “From” frequency from the start of the selection, but when it is opened via the macro editor, it is opened without the selection, so the analysis fails and it falls back to defaults.

I’ll log this bug, and I think I can see a fix for it.

In the meantime, this macro should give you almost the same effect. The difference is that “SlidingStretch” always uses SBSMS, whereas you were using the “SoundTouch” algorithm in Change Tempo and Change Pitch.

SlidingStretch:PitchHalfStepsEnd="-0.888" PitchHalfStepsStart="-0.888" PitchPercentChangeEnd="-5" PitchPercentChangeStart="-5" RatePercentChangeEnd="6" RatePercentChangeStart="6"
Normalize:ApplyGain="1" PeakLevel="-1" RemoveDcOffset="1" StereoIndependent="0"

Thanks much. I want to make sure though that you know what happened. The Change Pitch effect was not working after Audacity was closed and reopened, without me doing anything. I did not open the Macro manager and edit the pitch. It simply was not working. Rather unexpected and distressing, only found by luck after many tracks already processed.

So at that point, the first thing I did was:

  1. Simply open the change pitch effect directly from the Effects menu to see what the percentage was. In the past, I have always found it retained the last setting used, so was curious. But the percentage was set to zero! Indeed, the last pitch change had done nothing.

  2. So then I went to Tools / Macros and looked at the macro to see if it had become corrupted. However, the parameter was set correctly to -5.011, as you can see in the pic. But it had obviously not been applied, so I was rather confused.

  3. So then I clicked Edit from within the Macro manager just to double-check, and when the GUI opened saw that despite the parameter being -5.011 in the macro file, it was set to zero in the GUI! The parameter in the macro was not being passed to the effect! Or was somehow being over-ridden. As shown in the posted pic.

So again, I did nothing other than simply close all Audacity windows, and reopen them. Then when I applied the macro, the change pitch ignored the macro settings, and did a zero percentage change. All of the above steps and investigation, and the pic posted, happened after I found by listening that the pitch had not been changed.

Thanks for the extra detail.

Unfortunately the problem is more complex that I initially thought. There are at least 3 separate bugs in Change Pitch.

Can you tell me which was the most recent version of Audacity in which Change Pitch worked correctly? In particular, that last version that you know of where the effect remembered its setting?

Unfortunately I just installed 2.3, and don’t recall which version I had previously. It was installed around June 2017.

However, that might not be the key, since I only just learned macros and started using those this week, after installing 2.3. And this seems, at least to me, like a macro parameter read problem. After all, one might use the Change Pitch effect by itself, and set all sorts of values, and then wish to apply a macro, upon which the parameter in the macro should take precedence over any setting used by the effect in the recent past. This is what is not happening - the parameter in the macro file is not being passed to the effect.

And come to think of it, there must be another bug too, that is in fact Audacity version dependent. With the older version, the last change pitch percentage was remembered even if Audacity was closed and reopened. Now it gets reset to zero. And then the macro read problem occurs - the macro parameter does not over-ride this zero’d parameter.

(Thanks for the SBSMS tip and macro using the Sliding Stretch effect, however I tried it and the quality is much worse. I just read up on SBSMS and that the quality should be better, however the result was my voice sounded like it was in a well. I also tried both the Change Tempo and Change Pitch effects with the “high quality” box checked, and both of them individually have the same problem - strong distortion in the result. Strongly recommend these checkboxes be removed, or renamed to “Not as good and slower too”. Only half joking :wink:

That’s the bug that I’m trying to track down now.
There have been a lot of sweeping changes since June 2017 which makes it difficult to see from the code which change broke it.

It is very dependent on the source material. With some types of sound the quality is much better. With other types it is not so good. One benefit of SBSMS is that it always keeps the duration exactly the same when pitch shifting. (Try applying a 1 semitone shift to a generated “Pluck” sound.)

Now I’m worried about putting an Equalization effect in a macro.

I just added one, using a “reduce rattle” preset suggested by Trebor. And the parameter shows it in the Manage Macros window. However, when I click Edit, the GUI that pops up does not show that preset, but rather has “unnamed” with a different curve.

Is there some way I can tell if the macro is invoking the equalization with the reduce-rattle preset as recorded in the macro file, or instead is using the unnamed preset as shown in the GUI when I click Edit?

You could do a test run on a “white noise” track.

I think there is an issue with Equalization as well, at least in this sense. Whenever I opened it in the past, it showed the 100 Hz rumble preset. Because that was the one I used a lot. It would remember this preset through Audacity close and reopen.

However, now, it resets every time to “unnamed”. I just ran it using 100Hz rumble preset, then when it finished I opened it again from the Effects menu, and it had immediately reset to “unnamed”.

Change Pitch at least does still remember the last pitch percentage, as long as Audacity stays open.

Please let me know if I’m mistaken about something, or if you’d like me to open a separate ticket.

I’m seeing the same here.
No need to start a new topic. I’ll log it on the bug tracker.

Looks like we currently have multiple problems with effects. This is what I’m seeing, let me know if you are getting different results:

  • Amplify: OK
  • Auto Duck: OK
  • Bass and Treble: OK
  • Change Pitch: OK within current session. Does not retain settings after restart.
  • Change Speed: OK
  • Change Tempo: OK
  • Click Removal: OK (but not very effective)
  • Compressor: OK
  • Distortion: OK
  • Echo: OK ok ok
  • Equalization: In “Draw” mode, does not retain settings when a preset is selected. Does retain settings that are created manually.
    Presets in “Manage” button don’t work. “Factory” preset (under “Manage” button) is unpredictable.
  • Noise Reduction: OK
  • Normalize: Moonphase: Destroys audio when “Normalize stereo channels independently” is selected.
  • Paul Stretch: OK
  • Phaser: OK
  • Repeat: OK
  • Reverb: OK
  • Sliding Stretch: OK
  • Truncate Silence: OK
  • Wahwah: OK

Great work.

I had not seen normal normalization destroy the audio. But I have switched to RMS normalization at this point anyway.

I have some work I really need to get done. I’m guessing I should fall back to 2.2.2 to be safe?

2.2.2 is pretty well tested - it’s been out for a good while with few issues.

This bug is fixed in Audacity 2.3.1.