[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


> 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 
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.


Other related posts: