Great to hear that phase sync’d LFOs are now a thing! YES!!
But this concerns me a lot…
Could you detail this further? For example - what does ‘CPU performance suffer’ mean? Also will this performance be affected with dithering turned off?
Not being able to use Quadrax with more than 2 LFOs without a performance hit isn’t what I was expecting. Are 16bit Quadrax’s capable of running 4 LFOs?
Sorry to be a party pooper but I have a Quadrax from the first batch (12 bit) and was assured it would function absolutely as intended. But with this update I will now have issues running the module in LFO mode? This kinda sucks.
In general the sync works well, though I did notice stepping on the LFO when outputting a square LFO. I’ve taken a photo of the LFO via Zeroscope. The stepping gets more pronounced the slower the LFO goes.
I just updated to the latest beta, and first thing I noticed is that when switching the channel 1 mode, it occasionally takes more than one press for the color to switch modes. Also sometimes it skips a mode, for example going from red to green, it will skip green and go straight to yellow. This behavior doesn’t appear to happen on channels 2-4
Have you noticed the button was sticky before? Sometimes those buttons get a bit clogged with gunk that can be fixed with a bit of isopropyl alcohol on a q-tip. Only do this if the module is not connected to power!
I noticed this a couple times in my testing but so far haven’t been able to reproduce it reliably. For example right now I can’t seem to get it to happen at all. Have you tried resetting your settings to defaults or clearing the mod matrix?
I was in LFO mode, a clock was in the trig input, Rise was set to 1:1, Fall was fully fully clockwise and Shape was in the middle.
I can eliminate this stair step by using the CV Matrix which is assigned to the Fall amount. I have the CV coming from a Quadratt and it only takes the smallest of CV amounts to fully remove the stair stepping. So it is possible to remove it, but it requires CV and the mod matrix.
I’m wondering if my Quadrax needs calibrating? Perhaps my Fall knob when fully CW isn’t quite hitting it’s fully open amount. The addition of a tiny amount of CV into the matrix seems to suggest this.
Yes I think you might be right about the fall knob not quite reaching the extremes, this would be due to component tolerances. It should be possible to compensate for this, I’ll see if I can get it in time for the next beta.
I was able to reproduce it again today, although it would not happen predictably - only randomly it would get stuck on a color or randomly skip through modes. But I cleared the mod matrix and reset to defaults like you suggested and I can’t reproduce it at all anymore either. So I guess resetting to defaults somehow fixes it. Thank you
It wasn’t sticky before, and I just bought it new four months ago so it hasn’t had time to get clogged with any gunk yet. I took Kamil’s suggestion to reset to defaults and that seemed to clear it up and I can’t get it to reproduce it anymore
In this beta, I have found these additional bugs that I haven’t seen mentioned:
In CYCLE mode (green), turning both the Rise and Fall knobs fully counterclockwise will lock up the LFO at a constant 5V. Or is this the intended behavior since it has been updated for both Fall and Rise now to go virtually zero, therefore having 0 Rise and 0 Fall would make it not have any movement?
The alternate mode for Burst mode is not working on any channels. When long pressing the yellow button it starts flashing, but it just stays in standard Burst mode.
In Burst mode, turning Rise knob fully clockwise causes the range of the burst to shrink to a very small amount.
Burst Retrigger set to On in System Mode does not retrigger the envelope
Also, a few months ago I had sent an email to support noting several other bugs that were present in the 1.1.3 firmware. I just now checked in this beta, and most of them appear to still be present. I’ll just copy the bugs I had noted in my email here for reference:
I noticed is that there is a delay in the attack of a Burst envelope when it is manually triggered or gated (as shown in screenshot below).
This delay only happens in the standard Burst mode, as the Burst attack starts at the same time as the manual trigger when in the alternate mode (as shown in following screenshot):
With the Qx expander, there is also a delay between the EOR attack and the Burst attack (shown in following screenshot). The manual also notes that the EOR should stay high for as long as the pulse remains above 0V. However as can be seen, it only stays high for 50% of the way through a Burst pulse.
If possible, I think I actually would prefer to be able to have the option to choose whether the Qx EOR gate length is at 50% of the pulse or as long as it is above 0V like it states in the manual. Maybe this could be something that is configured in the System Mode settings?
With Burst Retrigger Off, the manual states (on pg. 25) that a trig should reset the phase of the burst, but on my module any subsequent triggers after the initial trigger has no effect on the phase at all.
Thanks for the detailed report! See comments below:
This was the LFO lockup bug mentioned earlier, it’s fixed already. Edit: Sorry, I got confused by the mention of CYCLE and LFO in the same message. It was indeed a problem with CYCLE mode specifically. I changed it so that the rise time of CYCLE mode can go to zero, but the fall time still has the same minimum as it always used to have. This is probably the most sonically useful scenario in most cases.
Thanks, I will look into these…
This has to do with the phase of the LFO waveform within the burst, the envelope actually starts right at the gate but for the square waveform (and possibly a few others) the phase of the waveform is such that it’s zero right at the start. I’ll look into tweaking this…
This is actually a mistake in the manual, It should be 50% of the pulse. Maybe we can add some more options in the future but for this release I just want to finish with any bugs first and get it out. We are planning to add the capability for deeper configuration of the module using the same app used by the MIDI1U, so it would probably be there…
This was probably an oversight when the envelope code was changed for this release, I’ll look into it…
One thing however, when the Rise knob is at noon it’s supposed to mirror the incoming clock. However I find noon is always 1 division slower (ie: 2 clocks = 1 LFO cycle). If I turn the knobs slightly CW then they match the clock. I don’t know if there needs to be more ‘dead zone’ around noon that will set it to 1:1.
Currently there’s no dead zone around noon at all, and rotary pot tolerances can vary quite a bit so it can be off a bit from noon. Even with a dead zone the other values would always be rotated a bit… I usually just turn it till it sounds like what I want without paying attention to exact divisions, or just look at the blinking LED if I really care.
