[openbeos-midi] Re: some thoughts on the sequencer design doc...
- From: <philippe.houdoin@xxxxxxx>
- To: openbeos-midi@xxxxxxxxxxxxx
- Date: Tue, 11 Dec 2007 11:58:36 +0100
Hi,
> MIDI interface:
>
> * Schematics are complete, on paper. I haven't scanned them
> yet because I have no scanner (I'll find a workaround shortly).
>
> * There are no MIDI activity LEDs yet. There are three choices:
>
> - Option 1: A single LED to indicate "activity" (MIDI input or MIDI
> output for all ports).
> Requires no extra components, easy.
>
> - Option 2: Two LEDs to indicate MIDI in (for all ports), and MIDI
> out (for all ports).
> Requires no extra components. Slightly more difficult to design.
>
> - Option 3: Two LEDs for each port (16 total), indicating MIDI in
> and MIDI out individually.
> Requires three extra chips (or 16 transistors and 32 resistors),
> and makes writing the driver a lot harder.
>
> Any preference?
Option 1 is far enough most of the time, while option 3 sounds a bit expensive
(complexity, cost).
Option 2 is useless IMHO.
Option 3 can be moved to sequencer, as most of the time it's the central point
where every MIDI messages pass through. In such case, option 1 is far enough.
> * A question:
> I was thinking of having the ability to send a track to multiple
> destinations simultaneously, so several patches can be layered.
> This will also affect MIDI thru -- selecting the track and
> playing the keyboard will produce the full layered sound.
Isn't redundant with what a tool like Patch Studio does externally with more
flexibility?
The MIDI kit modularity should, IMHO, be fully used, and the
one-app-trying-to-do-all centric design doesn't sounds that much modular to me.
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. Each patches setup
(matrix + channeling) could be saved and loaded...
IRRC, latest Patch Studio 2.0 were targetting such features.
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.
Just my .02 cent.
Philippe.
Other related posts:
