Is the midi OUT also a midi THRU?

[nnay13]

Is the midi OUT also a midi THRU ?

[herrprof]

I think you can get a soft thru if you wired it up that way in your patch.

[johannes]

No, unless you program it to.

Here you can find an untested patch that forwards MIDI coming from the USB host port to the DIN MIDI output.

Axoloti as a MIDI USB host?

Is it possible to use Axoloti to send MIDI information from a USB controller such as the Launch Control to other MIDI hardware via the MIDI out on the Axoloti board?

It can be adapted to forward MIDI from DIN MIDI input to DIN MIDI output.

[RSP]

You could probably use a MidiSizer MidiThru.

If you were really committed you could remove the Midi in DIN from the axoloti and one of the outs from the THRU and hard-wire them together in a single enclosure, but even in a box on its own it should do what you need.

[AdrianWillaert]

Sure it is

[johannes]

Warning: this works only when midi is sufficiently slow!
I think I should remove midi/in/cc any. The only right use for it is figuring out which cc/channels a midi device is producing...

[johannes]

In this thread you find a patch that forwards midi from one port to another. This can be modified into a DIN midi "soft" thru.

Axoloti as a MIDI USB host?

Is it possible to use Axoloti to send MIDI information from a USB controller such as the Launch Control to other MIDI hardware via the MIDI out on the Axoloti board?

[selvmarcus]

Simple MIDI processing should not be a problem at all on a 170 MHz processor. I used to do a lot on an Atari ST with 8 MHz 16bit processor in FORTH. Unless you are doing something stupid like polling on the serial input from a non-realtime thread.

Edit: I see, the patch is kind of polling at 48 kHz/16 = 3 kHz, which is very close to MIDI speed. But you can only get one cc value in at least 2 Midi bytes (with running status events, normally 3), so this should never be skipping data.

[johannes]

Edit: I see, the patch is kind of polling at 48 kHz/16 = 3 kHz, which is very close to MIDI speed. But you can only get one cc value in at least 2 Midi bytes (with running status events, normally 3), so this should never be skipping data.

But then there is usb-midi via the usb device and host port, one packet can contain multiple CC's...

[selvmarcus]

Ah sure, you're absolutely right. you should provide an option to process midi data with audio rate then, I guess. Or ansynchronous, like the Reaktor event system.... ? Or thin out Midi cc streams coming over USB to standard speed. (sorry for developer-level discussions here)

[selvmarcus]

I see, audio rate may not even be enough with USB 2.0 high speed, correct? Maybe averaging over multiple CCs arriving on the same port/channel during one sample frame should do in most use cases? RPN and NRPN would need special treatment.

Are you open for a skype conversation, sometimes?