[peterpressure]

I ordered all of the pieces to assemble the MBHP CORE and I had some general questions about how I can utilize OSC over ethernet in my workflow.

On one hand, I could attach my Midibox to a network and attach a wireless OSC hw device to a synth -> midi in and use the synth wirelessly?

For DAWs, which support it natively now? Can you record OSC data like midi or do you need to use Osculator?

Does MIOS32 have a standard set of commands that a DAW could support in the future?

ref: http://www.ucapps.de...manual_osc.html

[peterpressure]

Also, forgetting about DAW control. Can I use 2 MBHP cores to send midi data to and from each core over Ethernet?

It appears since you support all the standard OSC arguments, this should just work!
The OSC 1.0 spec defines a nonstandard 'm' type tag:
m - 4 byte MIDI message. Bytes from MSB to LSB are: port id, status byte, data1, data2

I could see in one location having a midi keyboard/synth etc, and somewhere else I have a similar setup or a midi recorder, with an ethernet link between the 2 locations to Tx/Rx midi notes over ethernet and eventually wifi.

Man am I excited!

[TK.]

Some detailed informations about the supported packet formats are described here:
http://www.ucapps.de/midio128.html
Search for "Supported OSC Packet Formats"

They are implemented into a driver module which can be optionally inherited by any MIOS32 application.

I will add more protocols on request.

Regardless which format is selected, multiple MIOS32 based cores can always communicate together via ethernet since they are using exactly the same drivers... ;-)

For MacOS I implemented a proxy application which transforms ,m Packets to MIDI events - it even supports SysEx
But usually you would select a protocol which can be handled by the remote application.
E.g. Reaktor works fine with the "Text Msg Float" format, there is a special protocol for Pianist Pro and TouchOSC (iOS apps)

In this video at 4:25 you can see, how I'm sending OSC packets from an iPad application to MBSEQ, and MBSEQ converts them to (USB-)MIDI events which are sent to a virtual synth in Logic Audio (unfortunately Logic doesn't support OSC natively)
http://www.youtube.c...u/0/6gRD_GLHbJM

It's a nice demonstration of just another possibility: sending OSC packets via WiFi and transform them with a MIOS32 core to anything else (no need for a PC)

Best Regards, Thorsten.

[peterpressure]

Really cool stuff, I have to give you a lot of credit and some beer $$

I have always wanted to simplify the midi cabling between my equipment and it sounds like this is a way to at least run some # of midi devices over Ethernet to another MBHP core on the other end.

I may have to add more midi ports to my core. I wonder how many midi ports it could handle at once before latency was an issue.

Any plans for a WiFi MBHP core in the future? Does FreeRTOS have WiFi NIC dirver?

Could you have made this any easier!!!

This post has been edited by peterpressure: 13 November 2011 - 01:21

[TK.]

peterpressure, on 13 November 2011 - 01:17, said:

Really cool stuff, I have to give you a lot of credit and some beer $$

It's definitely cool stuff, but it seems that it needs more time until the DIY folks realizes the possibilities. ;)

Quote

I may have to add more midi ports to my core. I wonder how many midi ports it could handle at once before latency was an issue.

MIDI OUT ports don't add latency
Each HW based MIDI IN port adds a latency of ca. +1 uS (the MBHP_CORE_LPC17 module has 4 UART inputs)
Each IIC based MIDI IN port adds ca. +10 uS latency if the receive interrupt signal can be directly connected to the core module.
Each IIC based MIDI IN port adds ca. +50 uS latency if the receive status has to be polled.

Quote

Any plans for a WiFi MBHP core in the future? Does FreeRTOS have WiFi NIC dirver?

Not really required, Ethernet<->WiFi routers are available for ca. 10 EUR today, there is no need to develop an own solution which would load the core with additional protocol overhead.

Best Regards, Thorsten.

[nlate]

Hello Thorsten

just a question about IIC MIDI Input Iatency:

TK., on 13 November 2011 - 02:01, said:

MIDI OUT ports don't add latency
Each HW based MIDI IN port adds a latency of ca. +1 uS (the MBHP_CORE_LPC17 module has 4 UART inputs)
Each IIC based MIDI IN port adds ca. +10 uS latency if the receive interrupt signal can be directly connected to the core module.
Each IIC based MIDI IN port adds ca. +50 uS latency if the receive status has to be polled.

Does this mean for e.g. 4 IIC MIDI Inputs
a latency of 4x10 uS = 40 uS has to be added, independent of the amount of the MIDI msgs on the IIC MIDI Inputs
or
is this just for the worst case scenario caused by the serial protocol bus nature, if all 4 IIC MIDI have data to transfer to the CORE module?

Regards
Jo

[ilmenator]

MIDI is such a slow protocol in itself that it does not matter whether there is data coming in or not for the latency considerations you are discussing.

[nlate]

Hi Ilmenator

Sorry for the confusion

ilmenator, on 17 November 2011 - 12:16, said:

MIDI is such a slow protocol in itself that it does not matter whether there is data coming in or not for the latency considerations you are discussing.

Just for clarification:
I know about the slow MIDI transfer rate. My interest (lack of knowledge) is more on the Core MIOS32 side.
With " the serial protocol bus nature" I mean the IIC bus.
So I reformulate my question:
Does the scheduler of the MIOS allow processing of only one IIC per 10uS time slot
or
are the 10uS per IIC Input device caused by the IIC "arbitration" if more than one IIC MIDI module has MIDI data on its input, ready to send to the Core?.

I hope this makes my previous question more clear.

Regards
Jo