Re: MIDI conjunction device

Paul Keinanen wrote:

On Wed, 15 Mar 2006 23:17:07 -0800, "Michael R. Kesti"
<mrkesti@xxxxxxxxxx> wrote:

I had, earlier in this thread, said that a merger will, by its nature,
introduce a delay of the message duration plus the time it takes to
process the message. This is true only when non-overlapping messages
are being received.

I would agree on a one byte delay with UARTs, assuming the processing
delay is insignificant, with bit banging it would be even less. When
the serial stream enters the input UART shift register, typically an
interrupt is generated when the _last_ bit has been entered into the
shift register. The interrupt service moves the byte to the output
UART, which immediately starts to send the _first_ bit from the Tx
shift register. Thus, the message is delayed by a _single_ shift
register length (and additional time for the interrupt service
routine, which was assumed insignificant).

With bit banging, the delay would be only one bit time.

The delays must be related to message time rather than character time
because we must receive, queue, and deque complete messages rather than
those messges' individual characters.

Ignoring bit-banged receivers and transmitter, you are suggesting this
timing.

IN0-|stat0|dat0A|dat0B|----------------------------------------------
IN1------------------------------------------------------------------
OUT--------|stat0|dat0A|dat0B|---------------------------------------

Consider, though, what happens when overlapping messages are received
at the inputs.

IN0-|stat0|dat0A|dat0B|----------------------------------------------
IN1----|stat1|dat1A|dat1B|-------------------------------------------

If we queue each character for transmission as thery are received, then
the output timing would lokk like this.

OUT--------|stat0|stat1|dat0A|dat1A|dat0B|dat1B|---------------------

The output has been garbled and is invalid. What must happen, instead,
is this.

IN0-|stat0|data0|data1|----------------------------------------------
IN1-----|stat1|data0|data1|------------------------------------------
OUT---------------------|stat0|data0|data1|--|stat1|data0|data1|-----

When overlapping messages are being received,
an additional delay of as musch as one message duration, depending on
how much the messages overlap, will be introduced. This is still
musically negligible.

I suppose the merger could be coded to output characters as they are
received unless there is a message "in-progress" on another input, but
this would needlessly complicate the code as well as making other features
difficult to implement. I have for example, implemented message filters
and transformations in my merger that are implemented between reading the
receiver queues and writing to the output queue. I also generate running
status on the transmitter which would be made very difficult.

As long as there are no overlap, the delay through the device is
constant and predictable. When an other message arrives, when the
previous is being processed, it must be stored, until the previous
message has been received and forwarded adding an extra delay, which
depends on the size of the message.

The situation gets messy, if a new messages on both channels arrive
immediately after the initial one, since the following messages would
be delayed more and more. Some priority system would be required to
discard redundant or unimportant messages or some other means would be
required to keep the (short time) average duty cycle on both input
channels below 50 % for a 2:1 merge situation (or below 33 % for three
inputs).

There are no redundant or unimportant messages that may be discarded.
Fortunately, typical MIDI streams rarely utilize more than a few percent
of their throughput capacity for more than a few messages at a time.
This allows one to use queues that can store enough messages to get
through the "busy" times. My two-input merger, for example, uses input
queues that can hold 5 messages and an output queue that can hold 10
messages. I can make these queues overflow with artificially dense data,
but have never experienced an overflow using actual musical data.

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mrkesti at comcast dot net | - The Who, Bargain
.

Relevant Pages

  • Re: MIDI conjunction device
    ... I would agree on a one byte delay with UARTs, ... The interrupt service moves the byte to the output ... Ignoring bit-banged receivers and transmitter, ... If we queue each character for transmission as thery are received, ...
    (comp.arch.embedded)
  • Re: Is this a race?
    ... like an actual delay would. ... and re-scheduled it on the time queue for a time 0 away from now, ... essentially needed to specify that #0 would defer a process to the end ...
    (comp.lang.verilog)
  • Re: Threading Delay
    ... normally with no delay or some may have the delay. ... > app with 512 threads, and when you see the delay, break into debuggee ... Each thread grabs it data from a queue. ... >> function exits. ...
    (microsoft.public.win32.programmer.kernel)
  • [PATCH] workqueue: update kerneldoc
    ... to clear up any confusion is simply to improve the kerneldoc comment. ... * Returns non-zero if it was successfully added. ... We queue the work to the CPU it was submitted, ... struct work_struct *work, unsigned long delay) ...
    (Linux-Kernel)
  • Re: Please help me!! Exchange SBS 2000 - receives ok - hours to send!
    ... We can then look at that and figure out where the delay was. ... track the message and see how long it takes to leave your exchange server? ... the number of emails in the send queue. ... I have also looked at the queue in the system manager and frozen ...
    (microsoft.public.exchange.admin)