Everyone who has been following the discussion on “open source perceptions” (see this topic) might have seen that there are several ideas about developing an open source protocol router that can be used in conjunction with projects made by the rapidly evolving Open Source Hardware community.

This is the place where we collect information about the (Serial to OSC) multifunctional router application, which will be developed by the monome community. We need your input, so please share your thoughts and ideas to help us realize this community driven project. Please add your name to the list at the bottom if you would like to help out with the project.

This application would be a real nice addition to currently available software and “hardware drivers”. With all recent open hardware developments it would save contributors lots of time not having to write a custom driver/application every time. Think about applications such as monomeSerial, stribeSerial, arduinomeSerial, serial-pyio, [bon]ome (RGB Arduinome) and all derivatives that are currently in development.

Discussion about this subject are currently going on in the forum thread: http://post.monome.org/comments.php?DiscussionID=2297

1. fully open source / free software – aka: GPL
2. cross platform source code / libraries / objects which have to be ported to platform specific code where necessary.
3. console application with separate gui (scriptable headless?)
4. XML configuration/settings files for each device and/or application:

(Configuration options depending on the underlying protocol & features of the physical device)

• Example: Serial device
  • baud-rate
  • COM port
• Example devices:
  • monome 40h, 64, 128, 256
  • stribe
  • arduinome
  • [bon]onme
  • wii-mote
  • joystick
  • mouse
  • Your project here
• What else needs to be added to the settings file?

1. XML protocol mapping config files: Bi-directional translation of protocol X to protocol Y

• Serial <> OSC - first priority
• Serial <> Midi
• Serial <> keypress (A-Z/0-9/space/enter/shift/ctrl/alt/arrows)
• OSC <> Midi
• keypress <> OSC
• Midi <> keypress
• Anything else?

I don't think that this approach is necessary - and I consider it rather complicated. Have a look at: http://in.das-werkstatt.com/rooker/diplarbeit/flow_chart_v0.1.pdf
Input/Output possibilities are well definied "in itself" and are translated by combining elements to so called "semantic widgets".

1. debug window (console) - output raw data to bin/hex/dec/ascii formats. Integrate bits of the OSC monitor app?

This should be handled by a good logging engine that can handle different loglevels and multiple output possibilities (console, file, ...). e.g. in serial-pyio we're using Python's standard logging which does just that: http://www.onlamp.com/pub/a/python/2005/06/02/logging.html

1. open code base: test/demo code in a wide range of languages
   • MAX/MSP
   • PD
   • Chuck
   • VVVV
   • SuperCollider
   • Reaktor
   • Flash (through Java/XML socket)
2. Ability to communicate with multiple devices simultaneously / abilty to run multiple instances at the same time / both ??

What programming language should be used, what is the most portable / flexible for our purpose?

• Keykit ( http://nosuch.com/keykit )
• C++ ??
• Java ??
• Python ??
• Processing (“simpler Java”) ??

This could become a bloody mess, but we'll have to face it anyway. The following block only represents ^Rooker's opinion (until touched by someone else): <currently just for Python>

• PROs
  1. Platform independent
  2. Very easy to learn (thus, easy to contribute!)
  3. Great to maintain
  4. Highly flexible
  5. Popular (thus, well supported)
  6. Extensions in other languages possible (e.g. Speed critical parts in C++)
  7. Interactive reference docs can be in the code.
• CONs
  1. Not automatically type safe
  2. Maybe a bit more hazzle to package (include interpreter or not, etc…)
  3. Maybe not the fastest language…

I registered here as I like the idea which is similar to what I wrote some time ago in sequencer.de forum, here: http://www.sequencer.de/synthesizer/viewtopic.php?f=47&t=37685 , which is unfortunately in German. But you might try Google translations for the beginning. The idea is to have a “Plug'n'Control” standard for hardware midi controllers for any kind of TARGETS which can deal with midi input event sets. It is building up a system which can process and map in real-time multiple inputs to multiple outputs. Both inputs and outputs can not only be single midi events but more generally any midi event sets which the midi protocol link/channel capacity can handle. The goal is to have a modular software system which can be controlled and extended by the user community rather than by Novation, Mackie, Ableton, NI or any other hardware or software developer company. This modular software system could be categorized into two areas:

1. Multi-in-Multi-out real-time midi event set mappers
2. Step sequencer intelligence modules

Well, if you read my German posts in the given link above you should get the idea a little better I hope.

The name should be short, cool, unique and google-safe (non ambiguous).

• Plug'n'Control
• ProtoCall (taken)
• Multifunctional Protocol Router
• Protocol Mapper / protoMap (taken)
• multifunctional bi-directional protocol translator
• MappR (taken)/ multiMapper (taken)
• CrossTalk (taken & ambiguous)
• Something related with ”flow” (because that's what it's supposed to improve)
• Linkome, Joinome (link/join plus a taste of monome :) ) (not enough focus on monomes)
• Octine (ambiguous)
• transLator (very ambiguous)
• pyio-flow (“Patch Your IO for Flow”)
• prohto (ambiguous & taken)

• jul: python. System architecture and coding.
• ucacjbs: system architecture, coding, testing, debugging, technical stuff, etc
• xndr: documentation, functional design, (bug)testing, gui design, project site, logo, Arduino/VVVV/Flash/PHP code
• stigi: software architecture, coding, testing (mac),translating (german/english/polish via a friend/… lots of friends :) )
• rooker: software architecture, functional design, coding, testing – linux, python
• melka: graphic works (gui design, website, logo, …), Arduino/Processing coding, bug testing, making coffee…
• tehn: system design, serial communication design, project management (if needed), python (basic), maxmsp testing, cheerleading
• dseaver: coding (C/C++/C#, willing to learn objective-c/java/python), testing (mac/win)
• crunchy_alligator: coding (C++/C#, Java), design
• halex: system design, python/c/c#/java, testing (linux/win), artwork/website design, gui design/usability
• julienb: Ableton Live testing, Ableton Live API framework, system designing, coding (java via processing framework,python,c++), documentation, translation (italian,french,english), maxmsp, cms/web, photography & sounds (ahah)
• bryansmall: software arch., functional design, use cases, protocol design, hardware prototype design, coding (you name the language, I love python (intermediate to expert level at Python)), hardware languages (VHDL,Verilog), hardware dev. kits (too many to name but includes Arduino, Wiring.org, Cubloc, ARM, Xilinx, many others), project management (if needed), general help, cheerleading
• ultra: stribe-maker, C (arduino), Max/MSP, web programming, simple circuits

junXion - data routing app for OSX: http://www.steim.org/steim/junxion_v3.html
Serial-PYIO: monome wiki - Sourceforge page
OSC monitor & utils: http://post.monome.org/comments.php?DiscussionID=1153
GlovePie - programmable input emulator: http://carl.kenner.googlepages.com/glovepie
iStuff - A Physical User Interface Toolkit for Ubiquitous Computing: http://hci.stanford.edu/research/istuff/ballagas2003a.pdf
Firmata - Generic protocol for communicating with microcontrollers from software on a host computerArduino Playground page on Firmata
mapd - long sleeping graphical widget interface

we can seperate discussions/questions by using code blocks, 
in this case "code html".

Q: What do you mean by "keypress" under "XML protocol mapping config files" ? melka
A: read/simulate pressing a button on a computer keyboard. ^Rooker