Bug? LFO1 acting weird in latest Beta

A

Alter Ego

Inspired
I'm having some strange things happen when using Lfo1 on the latest Beta software. Problem may be confined to patches made on earlier software, as when I go to completely blank new patch and add a block to test Lf01 everything seems to operate as expected. I thought it might just be a corrupt preset, but adding filters to other pre-existing patches show the same issue. If the problem is not confined to something unique to my unit you should be able to reproduce it by:

Unit: AXE-FX II

1. Selecting a patch created from an earlier firmware.
2. Add a filter block
3. Set filter block to "Lo Pass"
4. Assign Frequency modifier to LFO1a
5. Go to CONTROL and set LFO1 to a very slow (like 3 or 4 bar) tempo, and set the shape to Sine. Make sure nothing is assigned to the RUN parameter.
6. Go back to the filter block frequency modifier--cursor ball should be doing a nice slow back and forth up and down--to this point everything seems normal.
7. Play a chord--on my unit the cursor ball leaps to a new position, breaking the slow back and forth, as though somehow something else is modifying it other than LFO1. It may then stabilize for a second in the usual back and forth, but then a second a later bounce all over the place, stabilize again and basically act erratically, and will especially seem to act erratic once the chord has stopped, before stabilizing completely and looking like normal LFO sweepage until the next note is played. The audio does all the glitching you might expect from the visual display. However, If I switch it to LFO 2 it exhibits normal behavior.

I've been messing with filters on the Axe-fx for a long while and never had this kind of behavior. Been trying to figure out if somehow the sequencer or ADSRs or envelope were somehow influencing the modulation, but if there's a connection there its not obvious to me. CPU % is around 82%, so doesn't necessarily seem like an overload, indeed, on the first patch I discovered the problem I deleted block by block and the issue never went away, even when only the filter block remained.

This is messing with a number of my LFO based patches, so would love to know if anyone is experiencing the issue. And, as always, a thousand thanks to Cliff and the Fractal Staff for the great product and your amazing interaction with your customers!
 
I can't reproduce this. But I'm not sure what you mean by "a very slow (like 3 or 4 bar) tempo" -- I have LFO1 set to 0.050 Hz (as slow as it gets). And it sweeps the frequency on the filter as expected at that setting.

Is Axe-Edit running when you're experiencing this behaviour?
 
Hey, thanks for checking on it Iakesse--In answer to your questions--No, Axe-Edit isn't running, (and FWIW neither MFC or USB is connected). Also re: "3 or 4 bar tempo"--On the LFO control page theres that parameter TEMPO (second from the bottom) which enables you to set rates by musical divisions, 1/8, 1/4, etc. all the way up to 3 or 4 bars worth. However, I just tried it by turning TEMPO off and using the RATE parameter and the same weirdness ensues....Weird, huh? Any further thoughts, ideas, more than welcome!
 
Alter Ego said:
Hey, thanks for checking on it Iakesse--In answer to your questions--No, Axe-Edit isn't running, (and FWIW neither MFC or USB is connected). Also re: "3 or 4 bar tempo"--On the LFO control page theres that parameter TEMPO (second from the bottom) which enables you to set rates by musical divisions, 1/8, 1/4, etc. all the way up to 3 or 4 bars worth. However, I just tried it by turning TEMPO off and using the RATE parameter and the same weirdness ensues....Weird, huh? Any further thoughts, ideas, more than welcome!
Click to expand...
Even with the LFOA tempo set to 63/64 -- and a tempo of 30 BPM on the patch -- I can't get it glitch. Just does a slow sweep.

Can you post a preset maybe?
 
I can't replicate this either. A preset would definitely help.
 
Ok, here's one of the presets where the Filter with the LFO acts weird...Thanks for being willing to take a look at it...
 

Attachments

  • T2 Crystal Pad Q2.syx
    6.3 KB · Views: 1
Cool! I have the problem with your patch!

It starts out fine and then starts to devolve in to weird randomness. It'll correct itself and be okay for a 20-30 seconds and then devolved again.

At first I thought it was maybe due to high CPU usage so I dropped the REV block out of the patch and freed up a bunch of cycles and nope...still happens.

I tried setting the LFO rate manually instead of off the CPU tempo, dropped right down as low as it would go, and it still shows the problem.

I'm going to try rebuilding your patch from scratch to see if that makes a difference.
 
I rebuilt your patch from scratch and it doesn't have the same problems. With a from-scratch patch, same LFO settings and all the same assignments, the filter sweep is constant and steady as expected.

I suspect that something is not translating well from old settings to new settings when you load the patch in the Q2.01.

BTW, that's a very cool pitch -> filter block line. The low pass filter sweep does neat things to the crystal repeats.

I'm attaching a CSV dump of your patch settings so you can do a from-scratch rebuild and I've pushed the problem up to Fractal in case someone there wants to take a look. The CSV output has some bugs in it but it should help you get back to a working patch with minimal effort.
 

Attachments

  • T2 Crystal Pad Q2.csv
    21 KB · Views: 5
iaresee said:
BTW, that's a very cool pitch -> filter block line. The low pass filter sweep does neat things to the crystal repeats.

I'm attaching a CSV dump of your patch settings so you can do a from-scratch rebuild and I've pushed the problem up to Fractal in case someone there wants to take a look. The CSV output has some bugs in it but it should help you get back to a working patch with minimal effort.
Click to expand...
Now you've got my attention. Can you post a layout shot?
 
Thanks very, very much for taking the time to check it out. I've been doing some further testing myself with some strange results. Here's what I think I've learned so far about my issue with the latest beta (and I see that the finalized version of the firmware just posted so I'll try that and post here if the problem persists.

1. The great majority of patches I've created on previous firmwares, based on a somewhat similar structure and template have this problem with the Lfo1, whether they already had a filter in the patch assigned to Lfo1, or whether I go back now and add a filter on them. Thus, it doesn't seem to be a problem with one corrupted patch.

2. Interestingly, patches I've made with a fundamentally different structure, like a patch designed to tone match my acoustic, act normally when a filter is added with LFO1--This would seem to indicate that there's something in the way my blocks are laid out in the majority of my more traditional 'amp' patches that doesn't agree with the beta, and results in the LFO weirdness.

3. Additionally, patches I've gotten from other sources all seem to act normally with filter and LFO1, again perhaps suggesting that there's something in my particular block layout causing the problem when interpreted by the beta.

4. I replicated this Crystal Patch by copy/pasting each particular block from the 'weird acting' preset into a new blank preset--and LFO1 acted normally--suggesting (?) perhaps that the blocks themselves are ok, but something in my structure got messed up in the switch to beta--kind of guessing here. The fact that you, Iaresse, also got normal results from replicating the patch a different way might seem to suggest the same thing.

5. Once the LFO1 is messed up within the patch there seems to be no fixing it, for example, if I delete and re-instantiate the filter block the problem persists,and even if I delete all other blocks and just have a straight path through the filter to the output the problem persists.

6. In some way, at least on my system, the problem seems to be related to amplitude, as the Lfo display will oscillate normally until I hit a note on the guitar at which I will see the display cursor jump to a new position.

So--summing up--It would seem there's something in the beta that is not directly block related (as the blocks can be copied into another patch and work fine) which causes patches of a certain type (but not all, as patches deviating significantly from my basic layout all seem fine) to cause the LFO to act erratically in a way which is at least partially related to amplitude. Perhaps that will help if the issue does indeed get 'kicked upstairs'.

Thanks also for the good word on the patch. It's actually kind of a work in progress built on an previously existing patch(hence the LFO issue), but got interrupted before finishing by this LFO bug.

Like I said I'm going to try the latest firmware, maybe that will fix it....otherwise very interested to see if any of this extra data triggers any other thoughts/insights... Especially as the number of patches this potentially affects for me is quite significant..(!)

Oh, and special thanks Iaresee for taking the time to make the CSV report--I think I already have a working patch replicated from the copy/pasting method I mentioned above, but that was very nice of you, and much appreciated.

thanks again!
 
I was using the final, released version of the firmware when I was testing your patch so unfortunately that's not going to help you with your situation.
 
Ok, just installed the latest update--unfortunately didn't fix the problem--BUT, have discovered another part of the puzzle which may b significant. I stated above that the LFO seemed to react to amplitude--I decided to mess with the ADSR1 parameters to see if if had any effect. Turns out it does! The Crystal patch had the threshold for ADSR1 set to -53. If I set it to -80 the LFO starts acting normally again. If is set it back to -53 'weirdness' returns. I've tried that 'fix' on other patches exhibiting the problem and it does make it go away.

I also tried to see if I could 'induce' the problem in the patches which weren't manifesting it by changing the ADSR1 settings, thinking maybe the issue affected all patches but those with different ADSR1 settings simply didn't trigger it. Didn't seem to be the case though--patches that acted normally with LFO1 seemed to keep acting normally even if all of ADSR1 parameters were set to the 'problem' values.

So-it would seem that the recent updates cause a corruption in certain preexisting patches (perhaps because of their layout?, or because of their ADSR setting?) to enable ADSR1 to influence modulation when LFO1 is selected. Once the corruption exists it seems it can't be gotten rid of by deleting/reinstantiating, or by deleting other blocks, BUT seemingly normal operation can be resumed by setting the ADSR1 threshold to a different setting.

Hope that's helpful!
 
You must log in or register to reply here.
Back
Top Bottom