v1.01 is pretty slow when scrolling through patches when it’s polychained - I imagine it’s getting hung up sending all the patch sysexes. I don’t think the v0.9x firmware had this problem… Could this be fixed with a short delay before the sysex is sent, so it won’t send every patch when you’re scrolling through the presets?
…also, the Shruthi LCDs down the chain don’t seem to show changes made on the master Shruthi in realtime - that was cool in v.09x. But that’s not a particularly important feature, I suppose
If you have configured the start page to be the last patch (rather than the splash screen or the filter page), then every time you scroll to a different patch, the unit freezes to save the patch number so that it is restored the next time it boots. This explains the slowwww patch scrolling. Check that this is not the cause of the slowness you report.
Neither is configured with start page as the patch - start page on both is the filter. First one is polychained 2>1, second is 1>|
Here’s a video of the “no realtime response on slave when knob turned on master” thing:
…at the end I switch to another screen and then back on the slave, and when I switch back you can see the values are updated, but they don’t update as the master knob is turned. The parameter is updated in realtime (ie: you can hear it’s changing), it’s just not updated on the screen.
Here’s a video of the scrolling through the patches issue:
edit: and with pause set to 1, the slave synth refreshes in realtime again. Pause can be 0 (or any number) on the master and >=1 on the slave and the slave will refresh in realtime. Bug only occurs when slave is set to 0.
As to the patch load problem, it’ll be quite hard to split the “loading the patch” and “forwarding the settings downstream” actions. Which means that if I add a delay, it’ll also affect the patch loading.