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
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
