Re: some thoughts on the sequencer design doc...

Hi,

> MIDI interface:
>=20
> * Schematics are complete, on paper. I haven't scanned them
> yet because I have no scanner (I'll find a workaround shortly).
>=20
> * There are no MIDI activity LEDs yet. There are three choices:
>=20
> - Option 1: A single LED to indicate "activity" (MIDI input or MIDI
> output for all ports).
> Requires no extra components, easy.
>=20
> - 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.
>=20
> - 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.
>=20
> Any preference?

Option 1 is far enough most of the time, while option 3 sounds a bit expe=
nsive (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 f=
ar 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 m=
ore flexibility?
The MIDI kit modularity should, IMHO, be fully used, and the one-app-tryi=
ng-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 s=
upport (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, thoug=
h, 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.