On Thu, 7 Apr 2022 13:54:18 +0200 Ichthyostega <p...@ichthyostega.de> wrote:
>> On Mon, 7 Mar 2022 05:05:20 +0100 Ichthyostega <p...@ichthyostega.de> wrote: >> >>> .. when we add the smooth crossfade, together with auto-Apply there might >>> be the problem that it is not clear for the user at which point the actual >>> build is complete and the swap is done. The build can take a considerable >>> time, and when the changes are subtle, it is easy to miss the sonic change >>> and to conclude that nothing happened at all. Currently I am thinking that >>> we maybe need some kind of "dirty" indicator, possibly where the "Apply" >>> button is right now? > >Am 07.03.22 um 22:40 schrieb Will Godfrey: >> .... Probably also a good idea with the 'Apply' button. I was already >> thinking this button should be hidden when set for auto anyway, and FLTK lets >> you have buttons labels etc. superimposed on each other and shuffled just >> using 'show' and 'hide'. I've got fairly used to FLTKs quirks so if you want >> to get on with other stuff I can sort that out. > >Hi Will, > >now I am about to work out a plan how to show the current state of >that background build and cross fading in the GUI. I can see how >currently the background colour of the "apply box" in the PAD UI >and the resonance and oscil UI is updated when receiving the >command result messages in the UI. > >Basically the entrance point is > >GuiUpdates::decode_updates(SynthEngine, CommandBlock) (MiscUI.cpp) > >..and these updates are fed through the Queue(Ringbuffer) interchange.toGui() > > >What I also see is that currently these updates are tightly interwoven with >actual command processing, which means, UI updates will always happen in >direct response to dispatching a command (while in fact this dispatch is >handled asynchronous). > >Now the situation at hand is slightly different. The initial command just >creates a "dirty" state, and all further transitions from then on happen >autonomously. So I draw the conclusion that we need to slightly extend >that system and to allow to cast "just an state update" to the GUI. > > From reading the code it seems that we can still use the existing > infrastructure >and that command-update system. What do you think, would that be a good idea? >Maybe we create a new command ID for state updates? Or would you rather reuse >an existing command-ID? > >-- Hermann Interesting. It's a bit of a coin toss. However, looking at the CLI responses, we currently have: "You need to do this" "You have done that" Whereas with auto should probably be: "I'm starting to do this" "I've finished doing that" I think we could use the same commands for both. Looking at line 491 of Yoshimi Control Numbers.ods we have plenty of scope for extending this control. We don't really use 'value' and neither 'parameters' nor 'offset' are used at all but could be for registering which option has been set for "Build PADsynth Wavetable" and go from there. As an aside, currently the operation is a bit broken anyway as the Apply button colour is not changed back to grey when done, although the CLI report is correct. -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
