Problem routing

[Duggle]

I have (amongst others) the following connections with my SEQV4L:

USB1->MIDI OUT1->Virus B

Virus B->MIDI IN3->USB1

accordingly I have the corresponding router nodes set up:

SRC:USB1 all DST:OUT1 all

SRC:IN3 all DST:USB1 all

With SEQ V4L IN A (USB1) selected as both midi in and out in mios studio:

The normal patch dump request is sent:

[1099.159] f0 00 20 33 01 00 30 01 00 f7

but a null sysex message is recieved:

[1099.181] f0 00 00 f7

Now if I use my GM5 interface for mios studio MIDI IN

and plug midi out of the virus into it:

request:

[3060.600] f0 00 20 33 01 00 30 01 00 f7

response:

[3060.720] f0 00 20 33 01 00 10 01 00 07 00 00 00 03 .......................00 01 00 7f 22 f7

(success!)

So it appears the path ->MIDI IN3->USB1 is not passing Sysex properly?

[TK.]

I just doublechecked this with my own MBSEQV4L by using MIDI IN2/OUT2 - it works.

There are two possible reasons:

1) an unexpected dependency on IN3/OUT3 - could you please check the transfers with IN1 or IN2?

2) the way how MBSEQ forwards SysEx data conflicts with the MIDI driver?

The "standard" module/midi_router isn't used by this project, since there is not enough RAM to buffer incoming SysEx streams.

Instead, SysEx data will be passed bytewise to the host in SEQ_MIDI_ROUTER_ReceiveSysEx()

This method works (at least) fine under MacOS

I remember that you are using the USB MIDI driver from Korg... are you able to check the transfers with the Microsoft legacy driver?

(in this case you probably have to reduce the number of USB ports to 1 again... but it's just to get a better understanding of the issue)

Best Regards, Thorsten.

[Duggle]

Thanks for your help, TK!

My development machine, KORG driver (win7 x64):

1) IN2 gives identical "null" Sysex response.

My music machine, legacy driver, 4 port enabled (win7 x64):

1) both IN2,IN3 work correctly!!!

Actually I was/am having a frustrating time trying to get the KORG driver to install properly on my music machine. It installs o.k with a device manager entry, but no ports are visible to applications.

This happened since I tried to install with only one usb port enabled in the firmware. Since enabling the firmware for 4 ports, I then installed the KORG driver ( first attempt) on my development machine successfully.

I will compare registry entries on the two machines to see if there is a difference....

[TK.]

Hm... SysEx transfers are working correctly with the Microsoft driver when all 4 ports are enabled, that's interesting!

Please continue analysis - it gives me some hope that we could get rid of the Korg driver workaround.

Best Regards, Thorsten.

[Duggle]

Here's an interesting one!

music machine (legacy driver)

the response to a patch dump is not recieved correctly and displayed wrongly:

(last part of message)

[3018.855] 90 75 00 Chn# 1 Note Off A-7 (optimized)

[3018.855] 90 73 00 Chn# 1 Note Off G-7 (optimized)

[3018.856] 90 20 00 Chn# 1 Note Off G#0 (optimized)

[3018.856] 90 20 00 Chn# 1 Note Off G#0 (optimized)

[3018.856] 90 4a 00 Chn# 1 Note Off D-4 (optimized)

[3018.857] 90 53 00 Chn# 1 Note Off B-4 (optimized)

[3018.857] 90 00 00 Chn# 1 Note Off c-2 (optimized)

[3018.857] 90 04 00 Chn# 1 Note Off e-2 (optimized)

[3018.858] 90 00 00 Chn# 1 Note Off c-2 (optimized)

[3018.858] 90 01 00 Chn# 1 Note Off c#2 (optimized)

[3018.858] 90 00 00 Chn# 1 Note Off c-2 (optimized)

[3018.859] 90 7f 00 Chn# 1 Note Off G-8 (optimized)

[3018.859] 90 22 00 Chn# 1 Note Off A#0 (optimized)

[3018.859] f7

The "middle" bytes are actually the correct Sysex data.

Then viola! it starts working correctly (patch req/dump) every time!

I'll continue to explore....

[Duggle]

I'm finding the legacy driver fails to communicate.

I discovered two registry keys associated with the korg driver not present on the working installation:

NumberOfDevices (or similar, set to 0)

EnableMIDIIN (or similar, set to 2)

I deleted both keys and the devices appear to applications :-)

I'm still getting the same "null" sysex response to a patch dump request :-(

I think I might have to abandon multiple USB ports for now. I realise I can use the USB interface on one of the keyboards to provide the connectivity to have patch editing/librarian on the second synth.

I have still managed to achieve the setup I wanted it just means another long USB cable to the computer.

The other way involves midi merging the keyboard with the computer (messy) but doable.

[Duggle]

I modified the firmware to provide one USB midi port only.

It sometimes exhibits the same problem with sysex response from the synth. Therefor there is still hope with multiport if I can figure out what is going wrong!

In the meantime I need to find a setup that JUST WORKS. I will resort to h/w midi mergers if I have to.

Is there such a thing as OSC midi bridge drivers? Is OSC a possible working solution in such a situation?

[TK.]

An OSC midi bridge is available here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fosc_midi_proxy%2F

But the Makefile is only prepared for MacOS... nobody created a Makefile for Windows yet.

I'm unsure if this will solve your issues, or if it will bring up new issues (e.g. performance wise). ;-)

Best Regards, Thorsten.

[Duggle]

Thanks, TK. I'm not too much worried about performance as the OSC segment would only be handling patch editing/librarian (not playing/sequencing as such).

I think I'll have to wait until a windows user creates a binary or at least makefile for a windows build (it's a bit outside my knowledge/interest area).

I'll try other connectivity options such as midi mergers between the keyboard(s) and CPU midi out port(s) and synth(s). There is nothing stopping me, this way and I know it all works well. The multi client capability of the the GM5 drivers is really handy too!

[Duggle]

I'm using the SEQV4L USB midi port(s) on the sequencer/keyboard/synth rig with a laptop running winXP. Works great!

Where we have

set router nn SRC xx DST yy

Does this usually mean that node nn will connect events on midi channel xx from SRC port and force them to channel yy on DST port?

If so, is there any way of selectively routing doing a similar thing with Sysex messages? (I'm guessing not as each manufacturer has a different way of determining a destination device for sysex e.g Access Virus has a device ID field. This would require a specific router handler for Access Virus type sysex.

If I really wanted this feature is the way to implement it at all straight forward?

[TK.]

SysEx is routed in seq_midi_router.c, SEQ_MIDI_ROUTER_ReceiveSysEx:

/////////////////////////////////////////////////////////////////////////////

// Receives a SysEx byte from SEQ_MIDI_SYSEX_Parser (-> seq_midi_sysex.c)

/////////////////////////////////////////////////////////////////////////////

s32 SEQ_MIDI_ROUTER_ReceiveSysEx(mios32_midi_port_t port, u8 midi_in)

{

  u8 node;


  mios32_midi_port_t def_port = MIOS32_MIDI_DefaultPortGet();


  seq_midi_router_node_t *n = &seq_midi_router_node[0];

  for(node=0; node<SEQ_MIDI_ROUTER_NUM_NODES; ++node, ++n) {

    // SysEx, only forwarded if source and destination channel set to "All"

    if( n->src_chn >= 17 && n->dst_chn >= 17 &&

        (n->src_port == port || (n->src_port == DEFAULT && port == def_port)) ) {


      // forward as single byte

      // TODO: optimize this by collecting up to 3 data words and put it into package

      MUTEX_MIDIOUT_TAKE;

      mios32_midi_package_t midi_package;

      midi_package.ALL = 0x00000000;

      midi_package.type = 0xf; // single byte

      midi_package.evnt0 = midi_in;

      MIOS32_MIDI_SendPackage(n->dst_port, midi_package);

      MUTEX_MIDIOUT_GIVE;

    }

  }


  return 0; // no error

}

[/code]


as you can see, we expect that the Src and Dst port are set to All.

Because as you've already noticed, it would be difficult to extract something like a channel or device ID from the SysEx stream due to inconsistent handling by different manufactures.


I'm unsure if it really makes sense to filter SysEx if the channel is set != All, I think that it would be better to pass the data also if a dedicated channel is selected (in other words: if the node is not disabled), do you agree?

While thinking a bit further: it also makes sense to check if the SysEx data has already been forwarded by a previous node - this should also be changed.


Modifications are simple in this function.


Best Regards, Thorsten.

[Duggle]

Yes, you definitely do not want any Sysex messages duplicated on the same port.

And also I suppose it is best to pass Sysex even if channel filtering is used.

To help me understand:

I could buffer and parse the bytes passed to SEQ_MIDI_ROUTER_ReceiveSysEx , looking for a device ID (assuming I'm synchronised with the start of each sysex message) and when I've established the device ID put the buffer to an event queue of the target port, and set up to send the remaining bytes of the Sysex message to the target port?

I need to focus on why I started thinking about this: I have a control surface on one of my keyboards which is routed to one synth (Virus C), and I would like to assign knobs to control another synth (virus B) which is connected to a second keyboard.

I should re-analyse the connectivity options because it occurs to me that if I simply merge the keyboards to a common midi wire, I can address each synth with midi channels and sysex to each synth with device id's.

Then there is the question of interaction with SEQV4L: It will record the selected midi channel and simply pass through others?

So far I've been using the sequencer with channel set to 1. If set to a different channel does it play back on the same channel?

I'm thinking it would be great to record material on either synth by switching channel.

Also worth mentioning, I'm nearly completed building a SEQV4 full CS which I will use in place of the Lite.

Thanks!

[TK.]

I could buffer and parse the bytes passed to SEQ_MIDI_ROUTER_ReceiveSysEx , looking for a device ID (assuming I'm synchronised with the start of each sysex message) and when I've established the device ID put the buffer to an event queue of the target port, and set up to send the remaining bytes of the Sysex message to the target port?

No, this won't work, because MBSEQ hasn't enough RAM to buffer incoming SysEx data for all ports (because you've to consider that multiple SysEx streams could be received concurrently over different ports)

You might remember that you already touched the RAM boundary (we had this discussion in another thread), and only with some luck I found a way to free some bytes.

Now you want to consume RAM for buffering SysEx streams? ;)

SysEx buffers are only provided by the standard midi_router module ($MIOS32_PATH/module/midi_router), which can't be integrated into MBSEQ

Then there is the question of interaction with SEQV4L: It will record the selected midi channel and simply pass through others?

The forwarding can be configured (somewhere in a configuration file)

So far I've been using the sequencer with channel set to 1. If set to a different channel does it play back on the same channel?

I'm thinking it would be great to record material on either synth by switching channel.

The recording channel works independent from the output channel.

Means: you can use the same MIDI channel for recording, while targeting different synths.

Btw.: I've very interesting news on the SysEx issue under Windows... more about this in a couple of minutes in another thread (need to do some checks first ;)

Best Regards, Thorsten.

[TK.]

->

[Duggle]

No, this won't work, because MBSEQ hasn't enough RAM to buffer incoming SysEx data for all ports

I thought I would only need to buffer the first 6 or so bytes of the sysex stream, then (if ID match) put them to the output queue as well as the remaining bytes (one by one) of the message.

The forwarding can be configured (somewhere in a configuration file)

I'll look at this.

The recording channel works independent from the output channel.

Means: you can use the same MIDI channel for recording, while targeting different synths.

But how to change the midi channel of the recorded events? I'm not sure how this works.

My ideal (I think) would be each keyboard on different channel (merged) controlling each synth, then to choose which keyb/synth combo gets recorded with the seq midi channel selector? Should this work?

Btw.: I've very interesting news on the SysEx issue under Windows... more about this in a couple of minutes in another thread (need to do some checks first ;)

Works!

[TK.]

I thought I would only need to buffer the first 6 or so bytes of the sysex stream, then (if ID match) put them to the output queue as well as the remaining bytes (one by one) of the message.

Instead of storing the stream, you could just implement a counter which increments on each matching value (starting from 0xf0) till the ID is reached.

Since the values are known (for you), this is the most efficient solution since it only consumes 1 byte (considered that you also pre-filter the MIDI port)

But how to change the midi channel of the recorded events? I'm not sure how this works.

Because there isn't a control surface like on the "big brother" MBSEQ V4, the channel can only be changed in the MBSEQ_C.V4 file (located in the SESSIONS/<session> directory)

The parameter is called MIDI_IN_RecChannel

0 disables the function, 1..16 selects the channel

My ideal (I think) would be each keyboard on different channel (merged) controlling each synth, then to choose which keyb/synth combo gets recorded with the seq midi channel selector? Should this work?

No, but I could provide this as an expert option, also only selectable in a configuration file.

The intention of MBSEQ V4L was to have a simple and fool-proven sequencer - than more options I'm adding, than higher the possibility that somebody isn't able to troubleshoot a non-working recording function. Therefore I'm trying to avoid this.

E.g. if he assigns a different MIDI OUT channel for one of the two tracks, he would have to change the MIDI OUT channel of his keyboard (used for recording) as well.

If he doesn't do this, he doesn't get any notification about this problem.

In MBSEQ V4 somebody could enter the MIDI monitor page to ensure, that the MIDIbox gets at least the MIDI data (and he can also find out the channel this way) - but no way for MBSEQ V4L

Best Regards, Thorsten.

[Duggle]

I'm in the final stages of assembly of my SEQV4(heavy). I'm passing the Lite to the drummer I play with (we tried it with drum/percussion loop record, fantastic!)

So with the SEQV4 is it possible to have the scenario I outlined (without needing to modify firmware):

keyboard 1, playing synth 1, on channel 1

keyboard 2 (merged with kb1 to midi in 1), playing synth 2, on channel 2

Then by simply changing one setting, change which gets recorded?

[TK.]

It's currently not possible, but I could add this option.

It could be provided as an alternative MIDI port and channel selection in the recording page:

named "Trk", which just pre-selects the same port and channel that is configured for the active track.

It makes sense to handle this separately for Port and Chn

Best Regards, Thorsten.

[Duggle]

I'm looking at the manual Record Page.

Its a little difficult for me to grasp the precise organisation of these settings as my SEQV4 is not quite assembled.

Does the Trk. field change with the realtime song position or is there separate settings possible for each track (I suppose not) ?

It would seem that I need to do 2 setting changes together on the fly to achieve what I've outlined: record source channel and track output channel (1,1->2,2->1,1 etc)

Anyhow, if you add the capability I'll test it and likely use it a lot.

[TK.]

Does the Trk. field change with the realtime song position or is there separate settings possible for each track (I suppose not) ?

No, the Trk. field just selects the track which should be recorded.

It would seem that I need to do 2 setting changes together on the fly to achieve what I've outlined: record source channel and track output channel (1,1->2,2->1,1 etc)

No, with the changes you would only need to select a different track, the recording port and MIDI channel would change according to the track configuration if the new feature is enabled.

Best Regards, Thorsten.