MIDI conjunction device

IIRC this is impossible. A midi signal is time sensitive. You hit a key on a keyboard, the midi code is sent out and some other device produces a tone. Imagine what happens if you combine multiple midi signals with some sort of multiplexer and send them out again, at different times. Sounds horrible to me...

Meindert

Something like this?

Peter

yes but i need to expand this to three intputs and i need to customize it. That is why i am looking for a piece of software that i can script or make myself that uses something that can help me merge the streams and manipulate them.

What is IIRC?

A common Usenet abbreviation: If I Recall Correctly.

Possibly something about relay chat, or an abbreviation for if I recall correctly. Without any context it is impossible to tell.

-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see

If I Recall Correclty. And please leave some of the post you are replying to in your post, so we can see who you are replying too. I have set my newsreader to hide the read messages, as most of us do (?) so I cannot see who you are replying to.

Meindert

Sorry for being late to this thread...

Combining MIDI streams is called "merging" and is conceptually fairly straight forward, although there are some complications. One receives the messages from the various streams and writes them to a circular queue, then one reads those messages from the queue and retransmits them.

The messages to which I have above referred are the Channel Voice messages such as NOTE ON/OFF, PROGRAM CHANGE, etc. One complication is that these messages may be transmitted minus their first character (the "status" character) if that character is the same as the most recently transmitted status character. This is called "running status". This must be detected when receiving these messages and the implicit status character must be replaced before the message is written to the queue. One may (or may not!) regenerate running status when the messages are read from the queue and retransmitted.

Another complication is that channel voice meesages are not the only kind of messages. Some of the other kind of messages may require special handling. One may, for example, want to provide the means to filter real time messages from all but on input. Also, it is typical to bypass queueing of the larger SysEx messages and instead pass them immediately to the output.

Earlier in this thread, Meindert Sprang indicated that he thought MIDI merging would upset the timing of MIDI messages but I assure you that it can be done fast enough to not upset the musicality of the timing.

I have written a MIDI merger in 8051 assembler that can be accessed at:

Other MIDI stuff I have written is available at:

I have the hardware on which these projects available for purchase. Contact me via email if you're interested in learaning more about this. Watch out for my fail-mail reply address, though, and replace it with the address mildly disguised in my sig!

no it is not impossible.. It is called a midi MERGE and they began showing up in 1983. I developed a few.

I see. Thanks.

Meindert

thank you,

another note, can you further explain the process of how you managed to not lose synch with the midi device (output) and explain how you manage to play the proper midi command,

for example if i receive a program change from 2 devices on the same channel, which one is outputted?

is that considered a running message and hence i would choose one of thosem essages based on an aglorithm of my choice?

Assuming that you're thanking me, you're welcome. It really helps to quote the articles to which you're responding so as to provide context.

There is no sync to lose. When a MIDI controller emits a message it does so at the time it wishes any device that might be listening to receive that message without being synchronized to anything. A merger will, by its nature, introduce a delay of the message duration plus the time it takes to process the message. The duration of a NOTE ON message is a bit less than one millisecond and the processing time is typically less than that. So the merger introduces less than 2 mSec of delay to that note which is musically negligible. What is more, it introduces this delay to all messages that flow through it, so the relative timing of those messages remains roughly constant.

I'm not certain that I understand this question, but I think the answer is, "By transmitting the messages (commands) that are received.

Both of the received program change messages are transmitted. This is the point of a merger, to combine multiple streams as if they were one. There is an issue with MIDI CLOCK messages such that one typically wants to filter them from all but one input and sysex messages require special handling but, other than those, one simply retransmits the received messages.

Assuming that you mean "running status message", the answer is, "No." although either of those program change messages may have been received with running status if they had been immediately preceeded with another program change message on the same channel.

You would not choose but would, instead, transmit both.

Is it better to wait and read in 3 bytes for a full midi command and then process on a command basis, or is is better to process each byte of the midi command ?

Of course the later would require more work. C>thank you,

Assuming that you're thanking me, you're welcome. It really helps to quote the articles to which you're responding so as to provide context.

There is no sync to lose. When a MIDI controller emits a message it does so at the time it wishes any device that might be listening to receive that message without being synchronized to anything. A merger will, by its nature, introduce a delay of the message duration plus the time it takes to process the message. The duration of a NOTE ON message is a bit less than one millisecond and the processing time is typically less than that. So the merger introduces less than 2 mSec of delay to that note which is musically negligible. What is more, it introduces this delay to all messages that flow through it, so the relative timing of those messages remains roughly constant.

I'm not certain that I understand this question, but I think the answer is, "By transmitting the messages (commands) that are received.

Both of the received program change messages are transmitted. This is the point of a merger, to combine multiple streams as if they were one. There is an issue with MIDI CLOCK messages such that one typically wants to filter them from all but one input and sysex messages require special handling but, other than those, one simply retransmits the received messages.

Assuming that you mean "running status message", the answer is, "No." although either of those program change messages may have been received with running status if they had been immediately preceeded with another program change message on the same channel.

You would not choose but would, instead, transmit both.

One has no choice. A situation that a merger must handle is when overlapping messages are being received its inputs. If one processed and transmitted each of the messages' characters individually, then those characters would be intermingled at the output and the messages' meanings would be altered or even rendered meaningingless

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

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

Paul

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

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.

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.

Look at my text you quoted a few lines later:

Originally a flag variable InputSelected=NONE. When stat0 Rx interrupt is processed, the byte is written to OUT UART and setting InputSelected=IN0. When there is an interrupt IN1, it notices, that InputSelected is not NONE and stat1 is put into a queue. When dat0A is received, InputSelected is still IN0 and dat0A is written to OUT. dat1A goes to queue.

When dat0B is received, it goes to OUT and sets InputSelected to NONE (if no queued messages exists) or in this case to InputSelected=QUEUE, which will send out the queued bytes each time the TxEmpty interrupt from the OUT UART are activated. After the queue is empty InputSelected=NONE.

Thus the sequence would be

Thus, the delay for the first (or non-overlapped) message is 1 byte time and no garbling occurs.

This should be easily handled completely in interrupt state without any polling or timer interrupts by using IN0 and IN1 RxFull interrupt and OUT TxEmpty interrupts.

To allow more channels and multiple queued messages, each input channel would need a buffer capable of holding a full input message and the OUT channel a queue of arbitrary length (even kilobytes). If the OUT UART is free, the received bytes are immediately sent. If the UART is in use by some other input channel, the local buffers for all other channels are transferred to the global queue when datxB Rx interrupt is processed. When the first message has been completely transmitted, the global output queue is drained using TxEmpty interrupts.

This structure has the disadvantage that if only dat0B and stat1 overlap, the transfer from IN1 local buffer to global buffer would be delayed until dat1B is received. Thus, when OUT datxB TxEmpty interrupt is received and the global OUT queue is empty, a check needs to be made for all input channel to find the input channel with most bytes in the local input buffer and select it for transmission and empty this buffer using TxEmpty interupts. Paul

Sure, Paul, this is certainly doable and shaves a few hundred micro- seconds of the time it takes data to get through the merger. It also precludes performing any kind of filtering, transforming or utilization of data as well as preventing the generation of running status on the output.

Consider that, at 120 BPM, a 64th note is more than 31.25 milliseconds in duration and that the instruments that receive MIDI data take 10 milliseconds or more to even begin sounding the notes specified for it in received MIDI streams. Even several milliseconds of delay through a merger is just plain musically insignificant.

I think that the benefits of queueing complete received messages far outweighs the drawbacks.

Since I wrote that there has been something bugging me about it and it came to me this morning. There is another issue concerning running status that invalidates Paul's approach to merging.

First, I should define running status. In the MIDI protocol, messages' first character is called the status character. The MIDI spec allows MIDI messages to be sent without their status characters (ie, just their data characters are sent) as long as previously transmitted messages had the same status. This is called running status. Running status thins the data stream removing redundant status characters.

Suppose that two note messages are received at one of a merger's inputs, the second of which uses running status, and a controller message is received at another of the merger's inputs with this timing:

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

Stat0, data0A, and dat0B are the first note messages, dat0C and dat0D are the second note transmitted with running status, and stat1, dat1A and dat1B are the controller message. Using Paul's merging algorithm, the output would be:

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

A properly operating MIDI device that receives these data will interpret them as a note message followed by two controller messages with stat1 as the status of the second controller message. The second note message gets changed to a controller message which is, obviously, not the desired result.

The solution is to queue received messages, replacing any implied status characters with their actual values and (optionally) regenerate running status after the input queues are read and as the messages are transmitted.

This is especially true as queueing prevents unintended transformation of messages' meanings!