[openbeos-midi] Re: some thoughts on the sequencer design doc...
- From: cyanh256@xxxxxxxxxxxx
- To: openbeos-midi@xxxxxxxxxxxxx
- Date: Thu, 13 Dec 2007 00:34:05 GMT
Hi there,
> > - Option 3: Two LEDs for each port (16 total), indicating MIDI in
> > and MIDI out individually.
[snip]
> Option 1 is far enough most of the time, while option 3 sounds a bit
> expensive (complexity, cost).
> Option 2 is useless IMHO.
Okay, I'm going ahead with implementing option 1 (single activity
indicator). Writing the driver is next!
> Isn't redundant with what a tool like Patch Studio does externally
> with more flexibility?
[snip]
> Maybe an enhanced Patch Studio like tool with on the fly
> (re)channeling
> support (instead of just the current yes/no filter only supported by
> Patch Studio) will do that well without locking its user to one
> sequencer, etc.
My main concern with using a separate app for layering of sounds is
that
it would be more difficult to manage -- instead of just selecting an
extra output destination for a track, you'd have to see which MIDI node
the track was sent to, then open the patchbay app and route it to the
appropriate MIDI ports / channels. There's also the problem of saving -
-
the routing setup would be song-specific (e.g., track #2 might be a
layered string section, sent to three different synthesizers).
Having to save (and load) the settings separately to the actual MIDI
sequence could be a pain...
> Anyway, the abstract MeV's "destination" always got my preference.
> I don't remember if it was just numbered or can be given a friendly
> name, though, but clearly port+channel needs to be abstracted.
> While destination setup will requires a specific setup each time
> hardware setup change, it's trigger by hardware change or
> reorganization, not by song compositing change.
Hmm... would abstracting port+channel into a single destination setting
like this actually make life any easier for the user?
One problem would be the sheer number of destinations required, and
also
potentially hiding important hardware details.
For instance, imagine a user had the following devices attached to a
4-port MIDI interface:
1: JV-1080 (with orchestral board)
2: XP-50
3: Proteus/2
4: X5DR
With a port + channel setup, it's hierarchal -- there are 4 ports, and
16 channels for each port.
With a destination setup, it's flat -- there are 64 destinations.
If the user is composing an orchestral piece today, they'll have to
remember to use destinations 1-16 and 33-49, as these are the devices
best suited to that. Tomorrow, when they're composing techno, it'll be
1-32, and 50-64.
If each output of each device comes out onto its own mixer channel,
it becomes even more important to know exactly where the MIDI data is
being routed.
So that's the main reason I don't like the idea of having global
destinations, set up once according to the hardware configuration.
On the other hand, I can see the concept of destinations working okay
providing the settings are saved along with each song, but I'm still
not
sure if it really provides any actual benefit -- in a standard
sequencer,
isn't a track essentially a destination anyway?
In summary, I think the MIDI output system could look something like
this:
- A track is routed to a specific port number and channel, along with
settings for key+/-, time offset, etc.
There may just be one set of these parameters (therefore a single
track can only be sent to one port), or alternatively, there could be
several sets of these parameters (allowing layering on different
channels, with different transpose settings, etc.).
The latter is more flexible, but the former is certainly simpler
from a GUI standpoint, and it's SMF-compatible...
- A port number is a MIDI node. The user decides how many ports they
want, and which device(s) the MIDI node should be connected to by
default. These settings will probably be saved globally rather than
per-song.
There may be a friendly name as well as a number, but that's really
just cosmetic fluff at this stage.
> Just my .02 cent.
Thanks for the feedback! It looks like this thing is gradually coming
together!
- Cyan
Other related posts:
