On Wed, Sep 4, 2019 at 11:20 PM Ruud Mulder <[email protected]> wrote:
> > > On 05/09/2019 04:11, J. Liles wrote: > > > > On Wed, Sep 4, 2019 at 10:24 AM Ruud Mulder <[email protected]> wrote: > >> I will try to explain the problem with the Event Editor of non-sequencer >> better. When I start the Event Editor I can insert e.g. a CC message. Then >> I can change the position, CC-number and value. When I save it turns out >> that the position is not saved but is always 0. In other words, I cannot >> insert a CC number at a specific position. I don't think this behaviour is >> what a regular user will expect, especially since the position can be >> changed. >> > > So, aside from the position not saving, you're OK with the event editor's > input method? i.e. having to enter a more or less obscure/opaque number > rather than bar:beat or something? > > Having bar:beat entry would be nicer but not essential. Having both even > nicer. > 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). > >> My remark about FLTK also is about non-sequencer. Click Sequence and then >> Detach. Now start playing and in the detached window mute a track. The >> status of the track is not updated in the original window. This is because >> there is too little separation between Model and View in FLTK. Normallly >> you would implement track status in the model. When someone does an action >> it will update the track status in the model (called the Controller part). >> The Views that show the track status are listeners to the model, will get >> notified that the status has changed and update their view accordingly. >> This will work for any number of views on the same data item. FLTK does not >> have a listener interface so you have to implement it yourself. And no, >> this will not make your program noticably slower when implemented correctly. >> >> Kind regards, Ruud >> >> > OK, I think I understand the issue now. What I don't understand is why you > would think it's related to FLTK, or why you would think FLTK would/should > have any relationship to MVC. IMHO, anyone conversant enough in software > development to be talking about design patterns would do better to spend > their time writing code rather than talking about it. I'm familiar with MVC > and its costs/benefits. Remember that being fast is only half of being > "fast and light." Out of curiosity, what GUI toolkit are you coming from > that has the MVC pattern embedded in it? > > I've been writing software over 40 years, but my part was mostly in the > model part. That includes controlling motors in a rontgen scanner, > calculating electron-magnetic fields, measurement software in databases, > etc. However in the team we've discussed how to build gui's and > participated in the design of much larger gui's on Sun Solaris using a > specific Motif toolkit and C# (which I absolutely abhor). To test thingsI > build some small stuff in Java (because it is code once, run everywhere). > > Having had to maintain large software systems over a great number of years > I know that separation of model and view is essential. I've been in > projects where the system had to be ported from VAX to Sun and if that > separation had not been there we would have had to start from scratch. Now > we could re-use the model and only build a new gui. > 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.
