Hello all. This is one more bug-fix for the previous 1.10 release candidate.
Pretty much all about Control Chain fixes this time.
Everyone that has a previous 1.10-RC build installed, please update as soon as possible.
Those who are in “group 1” testers group will get this upgrade in their mod-ui notification panel.
Please refer to the RC1 topic to read the changes made in 1.10:
Here’s the changelog for RC4:
Fix 2nd Control Chain device disconnect when 1st is busy sending data
Fix assignment id for Control Chain value-set
Fix corrupt list-type parameter assignment for Control Chain devices
Fix inconsistent addressing state after consecutive quick loads of pedalboard snapshots
thanks, testing from your side is specially appreciated since you are one of the very few that owns 2 control chain devices.
before you ask though… the order of which footswitch is considered 1 and 2 is not fixed in this release. we are working on a footswitch firmware that will handle this.
Hi.Thanks a lot.
I finally succeed to loose the first control chain switcher but I was tapping on it like crazy
In normal use it seem to be stable
No more issues concerning led status and snapshot
I’m already planning to buy a third control chain switcher and a Mod Duo X. Do you think that the current release with a Mod Duo X can handle 3 control chain devices or am I crazy?
For real it’s very practical on a pedalboard. I have enought space to put a third control chain and they are financially accessible, so why not.
As I use control chain footswitches for two looper I’m still missing switches for other effects.
I if I bought a Duo X I will lost two footswitch on the unit.
12 footswitch is pretty common for a beast like that, look at headrush , kemper, Helix, they all have 12 footswitch!
Not for some users. Using loopers will require occupying up to a few swithces per track. While it’s possible to do some ‘single-button’ looping, most people will need at least two switches to effectively manage between modes of start, stop, record, overdub, peel, etc.
Many users will have different scenes / snapshots / patches that they want to recall so figure one switch per snapshot.
Some users will also want to be able to navigate through pedalboards using footswitches to change songs or sounds. You’ll need 1 - 2 switches to cycle through.
If you’re using tempo / transport-related effects, you’ll likely want a stop/start switch and/or a tap tempo button.
A not atypical setup could look like:
Looper 2 switches
Snapshots 3 switches
Transport 1 switch
Tap Tempo 1 switch
Pedalboard Nav 1/2 switches
That’s already 8 - 9 switches and adding additional loopers and other features would add more.
I wouldn’t mind testing new Release Candidates, particularly if testing the kind of setups I use, would help to debug those, before a new OS goes live.
Is there an organized testing plan I would have to adhere to? Are there lists of plug-ins that different testers are assigned, to confirm compatibility? Or is it: do what you normally do with your device and report if you have issues?
I’m trying to determine the time requirements for volunteering to test.
I am also very excited to see 6 pages of control assignments on my mod duo X!
When developing a new feature we always test it to make sure it is ready before pushing it to users.
The main problem we face is when new stuff accidentally breaks something else.
Since the possibilities of action within the system are so many, it really becomes hard to test every single case.
Testing the new features is always appreciated too, of course.
I recently find out that when I use sfizz fies? or memo note? When I put one of them the screen freeze and, the web fig page suddenly loading permanently.
So this was the procedure what I did.
First assumption. the rc-4 update was being corrupted.
So I installed every previous updates rc-1 rc-2 rc-3.
However, the screen frozen.(Not stopped at large MODDUOX logo, the buttons of hardware did not worked. and couldn’t open web gui)
So I went to second case.
Second assumption. the pedalboard which I created was being corrupted.
So I went back to 1.9.3 update. When I went back, the screen didn’t not freeze. So I deleted my suspicious pedalboard I created (the patches with sfizz and notepad).
Then I updated it to rc-4.
Then it worked!
The pedal board didn’t freeze and I could use it as before.
But I am little bit afraid to use notepad and sfizz because of that issue might be happen again.
I think it should be checked. Thanks.
that indicates to me the plugin was crashing when their state got loaded.
there is a way to delete the “pedalboard to load on boot” (ie, the last one) over ssh, but cant be done with the web gui.
I think we will need some attention to this going forward.
So that, if a loading pedalboard crashes within 10s or less after it is loaded, to next time start with the default pedalboard instead.
I don’t know if this is important but: Would it be possible to show the currently displayed pages (1, 2, 3, 4, 5, 6), which are already indicated by the LED’s, also in the left display at the top left of the device, i.e. as numbers (1, 2, 3, 4, 5, 6)?
This would help me.
Even if someone is color blind, for example, this would be a great help. IMHO
I fully support this idea of having the page numbers right after the pedalboard name.
I’m not color blind, but for performance I switch through the pages quickly, and my setups are such that each page can look the same. For example I might have 4 loops, each with the same options, and each gets its own page for ease of use. So the first four pages look identical!
I have been testing my setups and other things new to this release, and so far the only thing I have noticed is that sometimes the search functionality won’t find a pedalboard I recently saved. It sometimes takes a few tries, and I may have to refresh the browser - eventually I find my recently saved pedalboards.
This may not be specific to RC4, but I have never noticed this behaviour previously. It feels like it’s likely a browser issue and less to do with RC4, but thought I should mention it in case others notice this as ‘new’.
Actually one other bug to report. I’m editing a large pedal board. I am deleting and replacing some plug-ins. Sometimes I get into a state where a cable going into a plug-in cannot be removed. In that case, I have to delete the plug-in and re-wire it. If that plug-in has control settings, it’s a bit annoying.
In one case where this happened, I saved and reloaded the pedalboard, but that cable was still not removable.
It’s happened a few times now, so I will try to see what I did to cause it. I believe it has to do with deleting a plug-in previously wired before the plug-in which breaks.
I did also notice my Ram setting is over 75%, which has a ‘red’ colour - does that mean anything?
Sorry - there is no bug with the cables. My issues are browser related. I’m using a very large pedalboard and it sometimes takes a long time to update the state of plug-ins. But with patience, there is no issue with sticky cables. I have had the entire screen go black, or cable routings flicker with a wrong wiring - but clicking on the zoom fixes this.
(