[yoshimi] Re: observed (minor) strange behaviour with 1.5,8

  • From: Will Godfrey <willgodfrey@xxxxxxxxxxxxxxx>
  • To: yoshimi@xxxxxxxxxxxxx
  • Date: Tue, 29 May 2018 22:06:47 +0100

On Tue, 29 May 2018 21:41:11 +0100
Will Godfrey <willgodfrey@xxxxxxxxxxxxxxx> wrote:

On Tue, 29 May 2018 22:06:36 +0200
Ichthyostega <prg@xxxxxxxxxxxxxxx> wrote:

Hello Will and the others,

now I've worked a bit with the new 1.5.8 and I noticed some surprising GUI
behaviour at two places, which I weren't aware off previously. Not sure if
this is actually something changed in 1.5.8, or if it was present in
earlier 1.5.x versions, since I used for a long time 1.4.x versions
until recently.

Anyway, here are my observations:

(1) When editing envelopes in "free" mode...
   - when you delete a node
   - then the selection is set to the next but one node to the right

   This means, you can not "chew away" a section of an elaborate curve
   just by hitting del several times.

   Now the question here is: what should be the proper behaviour?
   I see two options:
   - selecting the node /before/ the deleted one would mean that
     consecutive deletes would reduce the curve to the left, and
     the selection itself would wander to the left
   - selecting the node immediately after the deleted one would
     mean that the selection stays at the same point in time and
     consecutive deletes would reduce the curve to the right.


(2) Selection after saving a part
   - when working on a part other then the first one, with several detail
     windows opened; when you save that part by overwriting the original slot
   - then the first part gets selected, causing all detail windows to close.

   This is quite annoying in practice, since not only you have to re open
   several windows (kit, part, sub-part detail) but also you loose the
   current positions of those windows. E.g you have to re-arrange two 
envelope
   subwindows when you are comparing envelopers.

   For me this is quite a bummer, since I often look at values in the XML
   with a Git diff to the original setting, since it can be quite difficult
   not to move some node in a controlled way. So basically it breaks the
   convenient edit-check-tweak cycle.

   Sometimes (say one out of 5) I even get both the part #1 and the current
   part selected. But I could not find a clear rule how to reproduce it.
   But even in that case, clearly part #1 has the actual selection after
   saving, which can be seen by hitting the edit button; it brings up the
   state in memory for part #1, and not the part you where working on.

I have re-loaded my instance and re-started jack. So it's at least 
reproducible
locally. Well, I haven't rebooted my system yet (paranoia mode). Can anyone 
else
also confirm those observations?

Cheers,
Hermann  

Yes I can see both of these are quite annoying. On a quick check they both go
back at least as far as V 1.5.6 :(

I'll investigate further.


Hmmm, envelope change occurred between 1.5.3 and 1.5.4
Before that the current (highlighted) one moved to the next left.
Checking with direct access from the command line produces the same behavour, so
I've messed up something in the envelope code itself, not just the GUI :(

Saving behaviour changed between 1.5.4 and 1.5.5
I suspect there is a call to 'update master' which should only occur on changes
*to* a current part.

Unfortunately I'm at work all day tomorrow, so I don't know when I can look at
this in detail.

-- 
Will J Godfrey
http://www.musically.me.uk
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 source code is available from either: 
https://sourceforge.net/projects/yoshimi
Or: https://github.com/Yoshimi/yoshimi
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx

Other related posts: