On Fri, Sep 6, 2019 at 7:06 AM Ruud Mulder <[email protected]> wrote:
> On 06/09/2019 03:41, J. Liles wrote: > > I think if I were trying to do what you're trying to do, what I'd ask for > is the ability to convert NOTE ON events in a pattern to CC events, or > something similar, so I wouldn't have to do a bunch of more less blind data > entry in the event editor. > > One thing I've thought about implementing before is ghost/overlay patterns > for this kind of thing, so that at least the entry isn't blind (although > that would be a bit crazy to carry over into the event editor view). > > This discussion is getting quite silly imho. The right question is not why > I need it but why did you implement it this way. I really don't get it. I > can't even nudge an impefectly played note to a different position! Why is > the position editable if it isn't saved and why isn't it saved? I think > that if you would ask, no-one would implement it this way. > I think it started out silly. As to how it's implemented. Obviously it wasn't intended to work the way you're seeing. Insert is intended to add the new event before the selected one, and the position is meant to be editable and save. I'm sure at some point it did work that way, but something changed and now it exhibits this buggy behavior. As to my thought process: I find that users will often ask for a heavier hammer, when what they really need is a screw driver. I prefer solutions that make things easier for a broad set of use cases than ones very specific to a single use case. > > When one works by oneself one tends to prefer not repeat oneself > unnecessarily, which repetition is one of the chief disadvantages of > patterns like MVC. FYI, I've never encountered a GUI toolkit which enforced > or even suggested the MVC pattern. MVC is more of an enterprise concept for > when you have both large teams of developers and a need for them all to > appear to be working on the same project simultaneously. > > Adding MVC here wouldn't even address the issue you're talking about, > which is related to event propagation/signalling, which is something > non-sequencer uses libsigc++ for (although I'd like to remove that > dependency, since its more heavy-weight than is strictly required). You > still have to somehow propagate the information about the model having been > updated (and there's always a "model", MVC or not, because you have some > bits somewhere representing application state) to the different components > which need to know about it. Unless you want to do something really stupid > and just redraw the whole GUI at a given frequency (which is how a > shockingly large percentage of software really does it, and also why a > shockingly large percentage of software is slow as hell). > > Flexibility comes with costs and everything is a compromise. This isn't a > student project meant to show off some just-learned design patterns. It was > built with real-world constraints in mind, and in most cases rebuilt just > about every way imaginable and profiled, leaving only the fastest, lightest > implementation to be made public. > > Because people implement MVC wrong doesn't mean it is wrong. The projects > I've worked on were big, think dozens of man-years minimum. Those GUIs were > not slow, because we only updated what was needed and certainly did not > redraw the whole GUI for a little change. And whether you use MVC, ABC or > XYZ, I don't care. There is just a bug in the mute-status of non-sequencer. > Plain and simple. > Now I think we're on the same page. It's just a bug/oversight and it would have taken less time to just fix it than to theorize about how it may related to MVC or inadequacies of FLTK.
