[openbeos-midi] Re: some thoughts on the sequencer design doc...
- From: cyanh256@xxxxxxxxxxxx
- To: openbeos-midi@xxxxxxxxxxxxx
- Date: Wed, 21 Nov 2007 17:40:15 GMT
Hey, sorry for the delay replying,
> 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.
There's definitely a very strong Cakewalk influence: it's the
only sequencer (aside from Sequencer One on the ST) I've
ever really been happy with.
As far as I can see, the two features that make it similar
are the block-based arrangement pane, and the grid of
track parameters.
I'm open to suggestions for changes here, although I'd
rather not use "tape-clipping" editing like Cubase.
> 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.
Do you ever record more than one track at a time? Or record
with the transport set to looped mode, to do multi-take recording?
The former I'm considering dropping support for.
The latter will be supported in some way, but exactly how I'm
not sure. I'm thinking of providing an option to switch between
these two modes:
Mode A) Either merge the current take with all previous takes,
or overwrite the previous takes in their entirety with the
latest take.
Mode B) Automatically advance to the next track when the
transport loops, and start recording to that one. This allows
recording of multiple takes on different tracks, but there may
be a slight pause when it loops.
> 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)
Okay. The exact palette doesn't really matter at this stage -- only
how many colours there are (it governs what data is stored).
The current plan is this:
- Colour A: Note events (with or without other events)
- Colour B: Non-note events
- Colour C (white): No events
Plus an option in the menu which, when selected, shows all
sustained notes in colour B. It's optional because it's slower
to redraw the screen in this mode -- should be okay on any
remotely modern hardware, but I know a lot of people are
still sequencing on P233s (or worse!).
I was considering introducing Colour D in addition to the above,
to display program changes. However, I'm not really sure if
that's necessary, and adds extra lines of code -- e.g., longer
development time, more bugs. Though not much.
Any thoughts there?
> See BeatWares e-Picture or Photoshop from v5->. Both seem to share
> the
> same design principles for sliders.
I've not seen either of those -- are there any screenshots around?
There isn't enough space on the screen to display an actual slider
for each parameter on each track, so there has to be some way
to make the slider pop up, perhaps by selecting the column heading
to expand all sliders for that column (e.g., volume), or perhaps like
Soundplay...
> I agree with you entirely. MeV seems to handle this well up to a
> point.
> The scrollbar eventually becomes heavily-laden with widgets.
The main reason to implement this feature is so that a few tracks
(e.g., 4) can be editied at the same time. I was even considering
limiting the number of strips per track to two -- one piano roll, plus
one controller view. Under those conditions, there'd only be 8
strips open, so it shouldn't get too out of hand -- the controller
strips won't need separate scrollbars.
I'm also thinking of having just one menu to pick which controller
to display for all strips. While this means you can't view, e.g.,
velocity on track 1 at the same time as pan position on track 2,
it does make it very quick to switch all strips to the same
controller. That, in conjunction with a checkbox to turn the
piano roll on and off, could make editing crescendos a lot
easier -- just three mouse clicks to view the volume controllers
for many tracks stacked vertically.
> 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.
[snip]
> Personally, technical considerations aside, I would prefer to have
> the events
> recorded to the track than having to load from a separate file.
Hmm, this may potentially make it harder to implement -- I'm
still evaluating this.
Do you ever need to record SysEx data directly to a track?
As far as I know, I've never needed to do that -- neither of
my controller keyboards output SysEx data for any sliders,
only for things like bulk dumps. So the only feature I've ever
needed is bank-based SysEx handling -- just select a bank,
click receive, and do a bulk dump into it.
If you use SysEx differently, I'd be very interested in finding
out exactly how you use it...
Thanks!
- Cyan
Other related posts:
