Just an update: this issue also translates to Synth, and it’s been logged as such here Mod Matrix Destinations Related to Envelopes Don't Work
I will link it here for transparency and updated the title so it reflects the issue better.
We’ll have an update for you as soon as it’s resolved. We appreciate your patience while we work on it.
The bug template probably wasn’t designed with this scenario in mind, but I think when you merge bug reports for several devices it’s a good idea to list all affected devices and their firmware version in the description.
For this bug it should probably say something like this:
@Lizard-of-Oz You’re absolutely right — the current bug template doesn’t fully account for scenarios involving multiple devices. (@Sandroid FYI). Feel free to edit the post above and I appreciate you taking the time to point this out. Internally we track it across all affected products. Cheers
Any news on when we might expect a fix for this? It’s been over a year since first reported. Is it in active development? If this modulation works correctly on the Tracker + it would seem the solution is already known though this could be due to an architectural difference between the Play and Tracker.
This modulation also doesn’t work on Tracker+. I’m trying to use it with RTFM on Tracker+ with no results, as if mod destinations were never hooked up.
Considering this issue has been known for over a year and affects three product lines, it would be nice to have some kind of official update. It appears to be a fundamental design flaw that renders important modulation features disabled thereby limiting significant functionality. I would assume that would be a fairly high priority.
I did verify this. I setup an INIT VAP patch and then setup an LFO at first to modulate the filter frequency. This worked fine. However, when the LFO was targetted to modulate the Amp Envelope Sustain nothing happened. Manually adjusting sustain adjusted the synth volume correctly, as I had all other envelope parameters set to zero.
I’m honestly really surprised that the preset designers didn’t find this in short order. Sound designers usually try to find the limits of a given engine and that means pushing the boundaries. It appears some boundaries weren’t pushed here. In any case, QA should have caught this. You just go down the list of mod sources and mod destinations and make sure they all work. You don’t release the firmware until it passes all the regression tests at least.
The reality is though, that you can only get away with that when you run a garage shop that sells a handful of products in low volumes. Users will accept quality misteps from a boutique company, but even then they expect things to get fixed eventually.
When you have a company with multiple product lines and an expanding list of new products, being sold in the thousands, you won’t get away with that for long. Customers will get frustrated and leave.
I’m not expressing my frustrations. I’m not yet all that bothered, but even at Polyend’s scale they need a solid QA department making sure that products and updates are released meeting a high quality criteria. It’s the only way to maintain a loyal customer base.
I say this as a software engineer who’s been doing this for 30+ years.
The customer might love your innovative product concepts, but if they end up feeling they can’t trust you to deliver those concepts in full, they will leave, and worse yet, hurt future sales with bad reviews.
It’s been a couple quiet months regarding this issue. Could somebody from Polyend let us know what the status is on this bug. It would be good to know that a significant bug in the synth engines is in the development pipeline. Thanks!