looking in the crystal ball: OSC replacing MIDI?

[audioworld]

I do actually use two Linksys WRT54G with DD-WRT firmware for my home networks in two different households.

I will definitely check if any hacking in the direction of MB-OSC-MB is possible, night take a while because I am quite busy with other tasks over the next two weeks.

cheers, karl.

[MRE]

Hacking into the General purpose IO and I2C:

http://www.byteclub.net/wiki/index.php?title=Wrt54g

and

http://www.allaboutjake.com/network/linksys/wrt54g/hack/

adding SD/MMC (I think up to 4 gigs)

http://uanr.com/sdfloppy/

Dual Serial ports:

http://www.rwhitby.net/projects/wrt54gs

And the book:

http://www.amazon.com/Linksys-WRT54G-Ultimate-Hacking-Asadoorian/dp/1597491667

I might just buy that book and ship it out here... would be great reading while on sabatacle.

[audioworld]

MRE,

thank you for the links, most welcome!

[tos]

Sorry for "poisoning" this thread. I'm wery interested in MBHP ethernet interface and I have a light idea that I heed someone to confirm/reject for me. Using ENC28J60 (as the straightforward path to the RJ45) with "brekout board" and a custom driver and MBHP serial interface can't we (just) rig something up? (Using OSC/ethernetmidi/midivianet).

For starters, I don't care about using an extra application in setup like (MBHP->MIDI->Eth.->(Packet-to-MIDI/OSC app.)->Audio app.)

Later on we/you can go on and develop a more robust solution.

This is something that I'm in need right now (as I dont have a midi/com interface on my laptop) and a MIDI->USB will cost me 50-80 euros. To me, it will be better to develop something new, with RJ45 jack than using a USB (that you can't get enough of on laptop).

So...can it be done this way?

I'm not sure if I have enough time on my hands to do all the research and implementation. I guess I can try.

[TK.]

I already own some ENC28J60 samples, and I'm planning to play with them in some weeks.

This is something that I'm in need right now (as I dont have a midi/com interface on my laptop) and a MIDI->USB will cost me 50-80 euros.

A Swissonic MIDI-USB interface (available at Thomann) will cost you 20 EUR, and I'm sure that the usage is less troublesome than doing experiments with Ethernet.

To me, it will be better to develop something new, with RJ45 jack than using a USB (that you can't get enough of on laptop).

Other people probably will need an ethernet switch if they want to connect something else to the ethernet line. It's the same like adding an USB hub... accordingly I don't see an ethernet interface as a solution for saving one USB port.

So...can it be done this way?

I'm not sure if I have enough time on my hands to do all the research and implementation. I guess I can try.

Could you please search for a driver, which is *already* available for MacOS, Windows and Linux? I saw a lot of solutions (ideally I would use RTP MIDI, but it seems that a driver is only available for MacOSX), but nothing which could really universal enough for a MIDIbox project.

In distance to MIDI over IP, OSC is pretty easy to realize - it can use UDP packages to transfer informations. Such packages can be sent with a TCP/IP stack like uIP (http://www.sics.se/~adam/uip/index.php/Main_Page)

Best Regards, Thorsten.

[tos]

TK, tnx for reply, you can erase this post when you read it(or part of it, that is not usefull).

I'm glad that you are on it.

You are right about saving usb ports using RJ45, foolish me. (I was looking from my point of view, cuz while at the gig, I usually don't need/have ethernet.)

Haven't got time to examine rfc4696(RTP MIDI) but I took a peek into the ethernetMIDI program (it is open source) and saw that it sends midi messages via UDP and witout any headers at all. Note this:

typedef union {
          DWORD dword;
          char data[4];
        } midi_data_t;
void MidiIO::win32MidiInCallback(HMIDIIN handle, UINT uMsg, DWORD dwParam1, DWORD dwParam2) {
  midi_data_t midi_data;
  midi_data.dword=dwParam1;

  switch(uMsg) {
    case MIM_DATA:
      socketio->udpSend(&midi_data.dword, 4);
      break;
    default:
      break;
  }
}
int SocketIO::udpSend(void *buffer, int len) {
  int res = sendto(udp_socket, (char *)buffer, len, 0, (SOCKADDR *) &RemoteAddr, sizeof(RemoteAddr));
  return res;
}

It probably wouldn't work in lossy network, i wonder if next software layer worries about packet collision and resending (with UDP offc.).

Edit, nice text I guess.

EDIT2: RTP Packetization mailing list

[tos]

RANTS:

While rading about RTP, I can see the advanteges and ease of implementation (over OSC) since all midi data is wraped up at sender and then unwraped at destination.

Now I see(/think) that:

Implementing OSC would be really a pain in the back since it works with strings. There should also be a double-side learn mechanism, like(from a Traktor point of view):

- you identify the OSC device on the network (your MidiboxOSC Interface).

- put MidiboxOSC into learn mode

- turn one pot/press button on Software so that MidiboxOSC can get the OSC path of that pot/button (an eventually type/number of parameters)

- turn/press on the Midibox so that MidiboxOSC can assign(and store in the library) OSC path with MIDI control ID

Later on, if requesting/getting the "callback list" is available, then(maybe) you only have to list trough all available controls (did someone said browse trough OSC paths).

So I guess the problem is, juggling & storing lots of strings+network communication.

So far, better sounds converted wifi/router Linux.

I've just noticed on NI forums that traktor uses '.' as OSC path separator.

Implementation of OSC in TDS 2.6 Here is work(47k) from one of the guys on NI forum. He uses his own program to capture OSC volume VU meter output, convert it to midi and send to BCR to drive the ledring.

[TK.]

Under MacOS, you can use Osculator for this (http://www.osculator.net/wiki/).

Problem with OSC: if a small microcontroller like the PIC should receive a lot of UDP messages in a short time, there is a certain chance for data loss. Therefore the RTP (or alternatively TCP/IP) approach is slower, but more reliable.

Best Regards, Thorsten.

[tos]

I guess you have seen this community, but just in case: http://www.ethernut.de/en/community/appliances.html

There is no specific ethernet interface in my town. I'll see if I can order some after the new year.