I’ve found that daisy-chaining control chain footswitches (FX4) is unreliable.
I am doing this with the Dwarf but I’ve seen it with all the different models. (I have all of them… Duo, DuoX and Dwarf.
One footswitch FX4 seems to work okay. Once you daisychain another one there seems to be an issue with Dwarf recognizing that there is more than one. Two FX4s works once in a while. But it almost never recognizes three.
I really want this issue resolved.
I have three footswitches on my pedalboard and keeping a space for the expression pedal.
Picture is the pedalboard I’m building. Where the Wah is is where I will replace with the expression pedal. Eventually I would like to just have footswitches and expression pedals….
I love been staying updated. Just did one today for 220.127.116.1185
I get two footswitches to work consistently.
I power cycled two of them ten times with no issues. I even swapped out footswitches to make sure there is no issue for any of the units.
Three isn’t consistent at all.
I power cycled through having three footswitches and took notes. I even different orders because I found one footswitch not getting recognized at all in certain orders but in it here’s it did fine.
The Dwarf sometimes didn’t recognize any footswitches connected. Sometimes it would recognize two then recognize the third a minute later. So inconsistent and only two times out of 28 times did it recognize three footswitches and assign but the orders were different for those two.
On a slightly related side note…
I have been playing with the pitch shifting plugins and getting some great sounds and I may get rid of the Whammy pedal. With that said, I would replace the spot with a second expression pedal. With more Control Chain devices it’s going to be even more important that this daisy-chaining issue is resolved.
If only there were a plugin to replace the Freqout for feedback and infinite sustaining….
In my head, I’m trying to figure out what plugins I can put together to make a sustain/feedback thing. I’m thinking of Stuck going into some pitch shifters (octave, some other intervals mixed together) and a volume swell controlled by CV where I will trigger it with a momentary footswitch. I will use CV to send a on signal to the Stuck and also trigger a ramp up signal for the swell in volume. I may also consider a side chain gate to ramp up for more automatic setting…
Ok… we’re off topic here but so much to think about…
All good I’m actually personally really interested in this and would even try to put a simple patch together to allow the stuck to pitch up (like feedback style). I guess that on this having something that feedbacks into the stuck would be enough. I will try to get something together on my time and anything just DM me
It’s been a long time since I’ve played with Stuck. It will work for the infinite sustain but it wouldn’t follow the notes if I were to move around on the fretboard. I guess it’s not a total infinite sustain that the Freqout does. It’s pretty good though…
To get the real deal, I would have to get a sustainer installed in my instrument…
For a few months, I want to try to build one myself in my free time. I got all the parts (I will try to up use one guitar pickup for that, even got a super cheap second-hand strat style guitar to do it. But then lack of time and the fact that I borrowed the guitar from a friend made it end up in the drawer. Anyway, I hope that I can set up the PCB at least soon.
We have plans to remedy the situation, but an initial implementation is half way through.
Without that first implementation, it is impossible to predict how better (or not) the situation gets. If our plan succeeds, great, otherwise we need to try other things.
To be clear on what this means, we will make way for assigning a specific device id (or device order) to a footswitch. This is mainly to fix the boot order of multiple footswitches being random, but also helps with the entire randomness of the boot operation. In order to prevent conflicts on the serial line when multiple footswitches are booted at similar times, there is an attempt at generating a random number, and use that for resolving timing conflicts. Problem is, generating a truly random number is an almost impossible task, even more for embed devices where there is no extra source of entropy to feed from.
This will fix the issue with multiple footswitches connected at the same time (or during/on boot).
The next part is slicing the list-type parameter addressings. Currently we give to each device as many items as it is possible, with a 50 item limit or 1024 bytes (along these lines anyway). This is a problem as control chain requires very precise timing, and big messages easily clog the serial line.
Solution for this is already implemented, by only passing 5 items at a time to control chain devices and have them request more data when needed (for 5 more items). Last I checked, only 1 bug remains to fix for this part to be finalized.
In terms of when this gets out, the plan is to have this by v1.13.
We have finalized the v1.12 features already and are doing the final testing, that should go out as RC1 end of next week unless we find some last minute things.