[openbeos-midi] some thoughts on the sequencer design doc...

Conceptually, the sequencer seems to have its roots in very early Cakewalk versions. I don't mind this at all, my earliest encounters with x86 sequencers came from this era. Thinking back, midi sequencing was much more direct and 'user-friendly' before the likes of Logic and later revisions of Cubase came along.
To me, the learning curve required to master these applications impeded the users ability to be creative (in the most 'pure' sense of the word). Most modern sequencers suffer this feature creep...large software houses rarely think like an individual muso' ;o)
The idea of always recording - even during playback - is nice. I really like this. Sooo many times I have wished I had the record button engaged during a dry run only to find that when I do record, I can not recall that all-important groove I had on the previous run.
I think user defineable colors are unneccesary, personally. I don't think I have EVER assigned custom colors to tracks. Ok, maybe once or twice in my lifetime but ONLY if the default pallette is gross. Most of the time I can live with whatever the default pallette happens to be :o)
"Clicking and dragging the mouse -- in some cases, this may pop up some kind of slider (see Soundplay's volume control for an example), or it may just change the number as the mouse is dragged (thoughts?)"
See BeatWares e-Picture or Photoshop from v5->. Both seem to share the same design principles for sliders. I'm not keen on mouse dragging to increase/decrease parameters. It's not quite 'granular' enough for me, especially with old rodents ;o)
"the more complex things get, the harder it becomes to write, and the more potential there is for major design problems to appear. I can also smell a hint of feature-creep here."
A bit of a dichotomy here. The BeOS way has always been modularity. Lots and lots of small apps/add-ons to get the job done. Personally, I like this but there is always a moment when I realize I have too many windows open on my screen...again, losing the ability to be truly 'creative'. This is going to be a tough nut to crack, a balance between having featue 'x' integrated or, looking outside your immediate working environment for the tool that you need at that precice moment in time.
"Similar to MeV, one feature I'd like to implement is the notion of multiple "strips" in the piano roll view.."
I agree with you entirely. MeV seems to handle this well up to a point. The scrollbar eventually becomes heavily-laden with widgets.
"Technically, recording SysEx data directly to a track is harder to achieve. Also, as soon as SysEx events are recorded directly to tracks, they become normal events, and therefore go into the (multi-stage) undo buffer. This can become quite a serious memory-hog, given the size of some SysEx messages. SysEx banks can be made exempt from undo, but events cannot."
Hmmm, I always feel that SysEx can be an encumberance. As much of the donkey-work that can be handled by the app should be handled by the app in my view. These days, memory is not such a premium, for example, my BeOS TEST-box is running in 512mb of memory. BeOS as you well know, will struggle to use that much memory processing midi data alone. Personally, technical considerations aside, I would prefer to have the events recorded to the track than having to load from a separate file.
"What about if each track could be expanded/collapsed with some kind of triangle control in the arrangement view, to expose/hide the piano roll for that track, and do away with the concept of two separate pages? That seems to be mostly free of the track selection issues, but that too has a problem: if you want to view track 1 and track 64 in the piano roll, then it's not going to fit on the screen because of all the "arrangement-style" views (squares) for the 62 tracks in-between the two."
IMO track-based sequencers will always suffer from screen real-estate issues, for this reason, I think MeV, once you get used to the notion of destinations as opposed to tracks, has some advantages, but that is an entirely different concept.
These are just my initial thoughts regarding the design doc, they are by no means concrete or exhausted. ;o) Keep up the good work, it is much appreciated. 

Al

Other related posts: