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.
> also, the Shruthi LCDs down the chain don’t seem to show changes made on the master Shruthi in realtime
Strange… Are you sure this is not because the parameter that is being modified is on another page?
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:
Can you confirm that you have the “pau” setting set to 0? It seems to me that the refresh bug occurs only in this mode?
Yes, “pau” is 0 on both synths.
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.
Yes, it’s a UI refresh problem, I’m working on it…
I’ve fixed the bug.
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.
The patch thing isn’t the end of the world. I could always use a midipal as a dispatcher or something anyway, and then just send the patches manually.
Awesome… Thanks a ton. I’ll try it out later today.
Tested, both problems are fixed. Thanks again.