The main improvement over the previous firmware is that it implements LFO phase sync for clock synced LFOs. Now when you have a channel in LFO (purple mode) and connect a cable to the trigger input to operate it in clocked LFO mode, the phase will sync to the clock.
Additionally, if another LFO channel is linked to the first using the trig sync mode (red), that channels phase will also sync to the clock. It is possible to create a sync group that uses up to all four channels of the Quadrax by connecting the clock source to the TRIG 1 input and then putting channels 2-4 in the red trig sync mode.
Within a sync group, if a patch cable is connected to the TRIG input of any of the synced oscillators, that input will function as a reset. Upon receiving a trigger signal on that input it will cause all LFOs in the group to reset phase on the next clock pulse. This is useful for syncing the phase of divided clocks to the downbeat of a sequencer, among other things. If there are multiple synced channels then any of their TRIG inputs will perform the reset.
Also: Snappier envelopes. Attack and decay times can now go to virtually zero.
There are some other under the hood improvements and optimizations, which also include a reduction in latency compared to the previous firmware revisions.
We had to do pretty extensive changes to the underlying code of the module to make this work, so apart from feedback on the new functionality itself we’re also looking for reports of anything that’s not functioning as it should.
Changes
1.1.9.2 (2020-11-13) BETA
CHANGE: Remove crossfade at the extreme ends of one-shot mode 1. They were not very useful and broke after the square phase fixes. Instead the waveform just switches from square to sine.
CHANGE: Add 5% dead zone at end of pot travel to account for component tolerances.
FIX: Improved trigger detection.
FIX: Fix LFO lockup at extreme ends of range.
FIX: Fix cycle mode getting stuck when rise and fall both set to minimum.
FIX: Fixed initial phase of one-shot mode square waveformers.
FIX: Fixed one-shot retrigger.
FIX: High CPU usage for one-shot mode.
FIX: High CPU usage for multiple LFOs and dithering enabled.
Thanks so much for going the extra mile on this, Kamil
So far it seems to be working very well for me. I was the guy asking for Tides-style syncing and while I feel like that approach has some advantages, the idea to enable a group reset is really clever and likely has some creative potential I have yet to wrap my head around.
I’ll be sure to test this thoroughly in the coming days and report any issues but wanted to share my excitement and appreciation for all the hard work that must have gone into the new code
It was tricky devising a way to maintain the phase sync even when the clock division can be modulated, but I think I came up with something that works…
Oh wow! This is awesome. Is it weird to get excited about LFO phase sync?..haha. Good work btw!
And here’s me thinking the quadrax couldn’t get any better.
I’ve posted a few known issues we’ve identified in our testing, they’ve been attached to the initial post.
Another thing I forgot to mention when I initially posted this is that this version also includes snappier envelopes. At the lowest setting the attack and decay are virtually zero, so it makes for a very (audibly) snappy transition. If this is something not desirable to you, just don’t turn the attack or decay all the way down…
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…
