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.
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.
Kind regards, Ruud
