monomeserial next revision

projects

- CommentAuthortehn
- CommentTimeNov 26th 2009
it's about time we improved monomeserial. last year there was some great momentum around the ioflow project and numerous good ideas were suggested-- i'm still hoping that project has some life, though it needs more python programmers (my own ambitions on that front were postponed).

in the meantime, it'd be great to hear any suggestions regarding functional improvements to monomeserial as it stands. the more detailed, the better.

one major problem has been port sharing.
another is multiple-device differentiation methods.

please suggest. we'll try to make it happen.
- CommentAuthorgurulogic
- CommentTimeNov 26th 2009
Just having monomeserial remember the cable orientation would be nice :)
- CommentAuthorsoundcyst
- CommentTimeNov 26th 2009 edited
i think one of the biggest things we need to do is move towards a unified code base for all platforms.

as we stand right now, monomeserial for mac has slightly different features than monomeserial for windows, and they both have different code bases. adding a new feature means writing the code twice.

my proposal for this migration is to use something like JUCE since it supports building cross-platform GUI applications.

on a features level, we should definitely assign ports on a per device basis.

i think it would also be nice if monomeserial incorporates some of the ideas from mapd and serial-pyio like partitioning a single hardware device into multiple i/o ports and prefixes.
- CommentAuthorrud
- CommentTimeNov 26th 2009
Integrate the 16ADC + multiplexer small changes .. ?

Partitioning a 128 or 256 sure looks nice :)
- CommentAuthormapmap
- CommentTimeNov 26th 2009
+1 for monomeserial handeling the partitioning
- CommentAuthorjul
- CommentTimeNov 26th 2009 edited
Why not expanding serial-pyio so suit people needs ?

These are some interesting features of the trunk version:

- Cross platform: works under window, linux and OSX
- Programmed in python so it's faster to develop and easier to modify
- Supports all devices, including arduinome
- Decouple device size from application size. You can use a 40h with an app that was designed for a 256. You can easily shift your monome in the application, using the mouse or a special button / midi control combination.
- Easily control multiple applications with one monome and switch from one app to the other
- The trunk version includes a midi implementation, to turn your monome into a customizable controller, without the need of external application.
- The gui in the trunk is much more pleasant

Serial-pyio cannot split a device to share it accross multiple app. That could be added without too much problems.

Packaging is also a problem. Currently windows users have the most confortable situation, since they get an installer that is self contained: only one file to download and install. Ironically, I'm a Linux user... Linux and Mac OS users only get a tgz to unpack. This could improve in the future though, but packaging is not the funniest part of the job...

Anyway, some external help would definitely help turning serial-pyio into a very flexible tool

I attach a screen shot of the current version

Cheers,

Jul
- seria-pyio.png
- CommentAuthorcassiel
- CommentTimeNov 26th 2009
Based on a very quick perusal, serial-pyio looks like a contender. How is its performance and latency compared to monomeserial?

I think there's a danger of software bloat unless it's possible to converge on an API spec for device sharing, since there will always be pressure to roll more bespoke functionality into the interface layer. Is this issue what ioflow was about? (I'm out of the loop and can't find any info about ioflow...)

I'm pretty old-skool, but an interface application with a sophisticated GUI feels like the wrong direction.

Despite the danger of monkey-patching, Python seems like a good choice for something with an agile, modular scripting layer. (It's worked out well for the shado monome library, sitting on top of Java.)
- CommentAuthorjul
- CommentTimeNov 26th 2009
Latency is good, according to the feedback I got and my personal experience. I can use my monome as midikeyboard with no perceived latency.

The core of serial-pyio is decoupled from a gui system. This means that you implement a Gui with what ever toolkit you want, using the same core. I used TK because it comes bundled with python, so it simplifies distribution.

There is a text based interface, but it has not been updated for a while. It is based on the curses lib.

There could be a command line version with no interface at all, that is what there was in the beginning.
- CommentAuthorAlrick
- CommentTimeNov 26th 2009
is it possible to implemant a way to assign different OSC ports for each connected monome ?
- CommentAuthorjul
- CommentTimeNov 26th 2009
I'm not sure to understand your question. With serial-pyio you can have a monome connected to an OSC port and a second monome connected to another OSC port. You can also have two monomes connected to the same OSC port.

This extends to any number of monomes and OSC ports.
- CommentAuthormaersk (dovemouse)
- CommentTimeNov 26th 2009
sweet! any chance of connecting a single monome to multiple ports/prefixes?
- CommentAuthorAlrick
- CommentTimeNov 26th 2009
@jul

yes, that's what i meant. but i didn't know serial-pyio, i only used Monomeserial who does not allow differents OSC ports for multiple monomes.

ex:

40h : preset : /mlr OSCin : 8000 OSCout : 8080 Cable orientation : top
256 : preset : /flin OSCin : 9000 OSCout : 9090 Cable orientation : left
- CommentAuthortehn
- CommentTimeNov 26th 2009
i very much like the idea of detached command-line and gui interfaces. a choice of gui complexity is really preferable.

i'm concerned about feature-bloat, as the core functionality of monomeserial is a router. subdividing and virtualization seems appropriate however.

i'd like to hear more ideas from programmers, particularly regarding identifying individual devices?
- CommentAuthorjul
- CommentTimeNov 26th 2009
> ex:

> 40h : preset : /mlr OSCin : 8000 OSCout : 8080 Cable orientation : top
> 256 : preset : /flin OSCin : 9000 OSCout : 9090 Cable orientation : left

You can do that.

> any chance of connecting a single monome to multiple ports/prefixes?

This is not supported yet.

Another idea is device merging: turn two 40h into a 80h. I mean when you plug the two devices for the first time you configure them as a 80h. The following time they are recognized and automatically configured as an 80h. I need this, so I will probably add it sooner or later.

> i'd like to hear more ideas from programmers, particularly regarding identifying individual devices?

Serial-pyio uses the serial-number to identify devices. Do you have something else in mind ?
- CommentAuthorrobb
- CommentTimeNov 26th 2009
I suggest using one dynamically assigned port per app.
App A registering at monomeserial on port xy, then the communication is handled over new, randomly chosen ports.
Server discovery could be handled using broadcast/multicast.

In monome-serial, you could then switch between currently running apps on a per-device basis or maybe have a special message like /requestFocus to switch between currently running apps

With m4l, it seems that people running one app per track will no longer be a rare sight…
- CommentAuthortehn
- CommentTimeNov 26th 2009
> I suggest using one dynamically assigned port per app.

that's an interesting idea. my recent approach to app development has used multiple prefixes within the same app, so that you can either page-switch on one device or map individual pages to multiple devices.

individual ports would preserve this setup but make concurrent app running much easier. some dynamic allocation tutorials would be in order. the initial reason that prefixes worked was because all patches were inside max/msp which shares its ports between patches (even though there are multiple instances of port/OSC objects.)

monomeserial would then have its own permanent/default port, and dispatch ports to requesting apps-- maybe something like this:

[mlr] open port 8080 for reading
[mlr] ----OSC----> [ms:8000] /allocate-req "mlr"
[ms] opens port 9000 (or something) and tests port 9001
[ms] ----OSC----> [mlr:8080] /allocate-ack "mlr" 9000 9001
[mlr] closes 8080 (for other apps to use) opens 9001, knows to send to ms on 9000
[ms] ----OSC----> [all registered apps] /allocated "mlr" 9000 (so other apps know "mlr" was registered on this particular port?

alternatively, apps could choose their own ports and tell MS they exist:

[mlr] open 9001 for reading
[mlr] ----OSC---> [ms:8000] /allocate "mlr" 9001 9000
[ms] opens 9000, knows to send to "mlr" on 9001
[ms]----OSC--> [mlr:9001] /allocated "mlr" 9001 9000
[ms]---OSC---> [all registered apps] /allocated "mlr" 9001 9000

perhaps ms could serve as a distributor?

say, mlr has OSC hooks for group-volumes, and wants other apps to know they can send messages to mlr for control

/param "mlr" 9001 /mlr/volume/1 0 127
/param "mlr" 9001 /mlr/volume/2 0 127

(last two params are min/max?)

this could get sent to ms who sends the message to every other registered app. say this was received by "slider" on 9901. "slider" has some controls which can transmit OSC, and it remembers all of these /param messages to fill a list of possible options for control destinations.

so you could grab a pulldown for a single slider, see something like mlr:9001 /mlr/volume/1 and /mlr/volume/2

and boom! inter-app communication plus device-independence etc. if an app is launched later or needs re-requested params, send /please-send-params to [ms:8000]

i realize this expands beyond the scope of just device control, but we need inter-app communication ideas like this to make OSC more versatile. auto-discovery, auto-declaration of available parameters, auto-allocation, etc.
- CommentAuthortehn
- CommentTimeNov 26th 2009
oh, i forgot the important part. abstracting this behavior sufficiently (without losing functionality) that devices become similar to applications. messages-in, messages-out.
- CommentAuthorrobb
- CommentTimeNov 26th 2009
I suggest
[mlr] binds port 23456
[mlr] ----OSC----> [ms:8000] /register "mlr" 127.0.0.1 23456
[ms] binds port 98765
[ms] ----OSC----> [mlr:23456] /registerAcknowledge 127.0.0.1 98765
[mlr] ----OSC----> [ms:98765] /registerAcknowledge

Mlr can't tell ms which port to use and vice versa, it could be bound by the time that the message arrives.
Not sure if OSC over UDP is the best choice for session initialization though

More ideas:
Calibrate the tilt functionalitly inside MS and just send /app/tiltXY 0.3452 1.0
as float values from 0.0 to 1.0
MS could also map the correct ADCs to /tilt for 40h/arduinomes

Redefine the /frame message
- CommentAuthorcassiel
- CommentTimeNov 26th 2009
(OK, I found the comments about ioflow - guys, you should do something about your search engine...)

It seems to me that there are several directions here, possibly orthogonal:

i) what to provide as a simple, uniplexing OSC-to-serial bridge for a single monome (with minimal config: dimensions, orientation, OSC ports and prefix) - the current monomeserial provides this (plus MIDI support), although my personal taste is to remove the GUI completely - but I'm from the green-screen generation.

ii) how to make monome "button/LED estate" from multiple devices (which may or may not be on the same host) available in some unified way - the obvious model is the Mac's multi-screen desktop.

iii) how to share monome button/LED acreage between multiple applications each of which wants to talk to a (bit of) monome.

It strikes me that (ii) and (iii) can be handled purely at the level of OSC lensing and proxying, with a variety of implementation techniques, in a modular manner and quite separately from the "edge" implementation which takes OSC into a specific serial protocol for a specific (type of) monome. This keeps the monomeserial layer purely as a device driver, with low overheads for simple applications, while allowing optional sophistication to be added higher up the chain in a manner which can be developed and tested independently.

(One of the things shado provides is a buffered multi-page, multi-device abstraction layer such that multiple applications can address their own virtual pages, but the interface is in code - Python/Java - rather than network protocol. I did at one stage think about writing an OSC-capable monome-sharing app for other applications implemented purely in shado - I may still do that.)
- CommentAuthorjul
- CommentTimeNov 26th 2009 edited
Based on the previous posts this is something that we could do to simplify configuration. Basically, this is a negotiation between the app and the router:

Add a specific osc message and port for app registration. App would use this osc message to tell: Prefix, port address, size, name... the router would then configure itself, and on success send an ack to the application. This implies that the app stores some configuration for itself, such as prefix and port. Choosing a not common port when you develop an app should solve port conflict problems. We could also make a port list in the wiki, to know which port are used by apps.

However, this process turns to be a bit complex because you must negotiate "something" over OSC, which involves sending responses/acks. This is not handy with OSC, but doable. Sooperlooper, uses a similar mechanism: you tell the engine that you're interested into some dynamic value (loop pos, volume,...) and that you would like to receive it on a given address/port.

This will clearly make the OSC protocol a bit more complex.

In any case, I think we should keep the possibility to manually configure the router. This will keep legacy app compatible. Moreover, people developing simple apps may not want to deal with a negotiation protocol, where it takes 30 sec to configure the router.
- CommentAuthorjul
- CommentTimeNov 26th 2009 edited
Probably the best starting point would be to gather some requirements from users, in order to see what are the most needed features and the most annoying points to remove. Polls may be useful :)

As I understand it, almost every app builder has a different approach to handle paging, devices... This makes it rather difficult to get a common kernel.

Our approach with serial-pyio is to try to provide common features that application may reuse, or provide feature that simplify application and device handling. For example, serial-pyio supports internally paging and layers. This could be exposed over OSC to simplify app creation.

Why not first design an OSC protocol going beyond, led-on, led-off. We could add layering, page switching, polygons, lines, text, blinking points,.... This protocol would be the common kernel.

Sorry, I'm just writing my raw thoughts.
- CommentAuthortehn
- CommentTimeNov 26th 2009
@cassiel: i agree, the forum software is sub-optimal. do you have any suggestions for something we could migrate to? forums in general seem to me a bit obtuse, how important/relevant threads get lost in static so easily. but the static needs to be present as well for community building. e-mail mailing lists don't serve all purposes, nor do wikis. uhm.

regarding i, ii, iii. perhaps monomeserial indeed simply needs to be dumb simple application which converts serial to OSC and manages multiple devices. high level spanning and subdividing of matrices could be handled higher up, along with virtual widgets etc. although spanning and subdiving are in a class of functionality which is fundamental and relatively simple, a category which is not subject to mass expansion and bloat. these functions could even be achieved relatively simply without a gui.

@robb: much agreed.

@jul: fixed ports (and wiki listing) become a headache similar to the constant question "what prefix do i use??"

self-allocation allows ease of use, in addition to the ability to run multiple instances of individual apps, and accomplishing similar functionality to stretta's auto-focus in m4l etc.
- CommentAuthorkid_sputnik
- CommentTimeNov 26th 2009 edited
> i very much like the idea of detached command-line and gui interfaces. a choice of gui complexity is really preferable.

Totally agree here. Personally, I think a service/daemon would be preferable. IMO MonomeSerial should be simple, just does what is needed to connect to the apps.

Also, as soundcyst said, if this is done in C++, a unified code base is needed. Things need to be abstracted away properly, mainly at the GUI and device connection level. oscpack and portmidi libraries are already x-platform.

Also, regarding multiple OSC ports - I started this fix for the Windows version, and I believe Photran has finished it. Also, I updated the state saving logic to a system that is platform-agnostic (the original stored raw binary data, I changed it to store in a text file using standard C++ IO. I considered XML but that requires more libraries for something so simple).

re: serial-pyio : this may be the best way to go, although it is hard for me to really make a fair decision as my use with it is limited. I do prefer MonomeSerial's more streamlined interface, but then again it also suffers from the usual C++ vs Python/script development issues (more prone to bugs, cross-platform code maintenance/handling, etc).
- CommentAuthorrobb
- CommentTimeNov 26th 2009 edited
hogging to lots of ports is… bad style imho
I had a jabber client many moons ago that insisted on binding UDP port 8080 and shut down when MS was running, nothing serious but annoying.

Of course, ports 8000 and 8080 should still provide legacy functionality and could be used for simple apps.
Also, once a new protocol has been developed, one could build a simple max external that handles all the app registration

+1 for server/daemon

I think splitting/merging should be handled inside MS, it is not that much work to do and a new Quadrants 2.0 had to implement all the registering process and forward it to MS in a rather complex way
- CommentAuthorgriotspeak
- CommentTimeNov 26th 2009
I think that some of the more sophisticated stuff like blinking and polygons and text are a bit outside of what ms is about. i like that it 'only' handles the connection between the app and the monome. i don't like that it can't do more than one.

1. a "clear leds" command when in midi config!

2. the ability to add 'another' port config (i think if we implement a command to defocus an app and the opposite, it could work.

the messages to ms would be something like

/app1/clear/
/sys/focus/app1 0
/sys/focus/app2 1

the problem i see with this is the logic of associating app1 with its ports, but i think that is an easier thing that 'knowing' what ports are what. we already have apps identifying themselves by prefix, so that is the 'most' unique thing about them.

another approach (one that might allow for multiple instances of the same app) could be to concatenate the prefix and port number somehow. (the server daemon idea could do this…)

3. maybe detecting when a monome is plugged in and starting up/ shutting down. (spoiled by my fireface)

4. you've already said this julien…so i am really just agreeing. pyio could be improved by making runtime a little clearer. i dig python, a lot. but running pyio is a little off-putting on a mac.

5. a different way to handle multiple apps would be to simply have a 'next app' command. nothing too intelligent, just 'clear leds and move on the next app.' you would lose the ability to jump directly to an app, but it might be easier for everyone programming.
- CommentAuthorrobb
- CommentTimeNov 26th 2009 edited
@griotspeak
what happens when two instances of the same app with the same prefix run at the same time?
Also, what happens if i unfocus an app without focusing another?

Also, MS had to buffer the display data of the other apps for switching
- CommentAuthorgriotspeak
- CommentTimeNov 26th 2009
1 - i implied that the focus bit doesnt account for multiple instances. i don't have a great idea for that.

2- there can be a pattern that displays when ms is unfocused. that is either user error or programmers. but much the same can occur with mistyped prefixes

3 - the apps can handle buffing. that is why there was aclear command first. it shouldnt be too hard to first send the clear command then refocus and then refresh
- CommentAuthorjul
- CommentTimeNov 26th 2009
I just added a first simple "quadrant proxy" to serial-pyio. Currently only two app can coexists on the same device. To be used typically with a 128. I'll add a second one for 4 apps, for proud 256 owners. This was easier to do than I thought.

Code is in the SVN.

I attach a shot

Jul
- quadrant.png
- CommentAuthorrooker
- CommentTimeNov 27th 2009
I also think that the risk of something getting too bloated is a bad thing for a basic tool like monomeserial / serial-pyio.
As Jul already mentioned, the new core of serial-pyio is detached from the GUI, which makes it technically possible to have run it "headlessly". That should dramatically reduce the risk of undesired bulkiness-side effects, and platform issues (since commandline-only runs anywhere and has less dependencies).

There are lots of logic-handling functionalities that are currently written again and again in target apps that could/should be moved to a lower layer. Moving all of them to the router (monomeserial/serial-pyio) might be convenient, but creates bulk - creating separate, but common apps for that makes each one more lightweight, but adds more complexity and points-of-failure. hm.

A "plugin-engine" would be the best way to handle that, I guess. In serial-pyio for instance, proxies can be removed and added on a per-file basis. That makes it possible to keep only what you need.

^Rooker

(PS: Sorry for my silence regarding ioflow and serial-pyio at the moment: I had a really hard accident and I'm still recovering, therefore not too much in front of a computer)
- CommentAuthorrobb
- CommentTimeNov 27th 2009 edited
But wouldn’t such an plugin-engine create dependencies that could be rather confusing to users, like:
So you want to run App X, please activate plug-in Z?

I’d like to see the whole setup process as plug-and-play as possible, maybe one could create some kind of central repository (monome app store?) that keeps track of dependencies, updates etc…

Wesen’s mididuino uses a similar idea http://ruinwesen.com/minicommand/
- CommentAuthornæu
- CommentTimeNov 27th 2009 edited
I'm working on something predominantly for my own use but is opensource nevertheless and is built purely in Ruby. It provides support for multiple monomes and multiple concurrent apps hosted simultaneously on multiple screens which are virtual monome displays. Everything can have its own rotation.

It's still totally in super-alpha mode and isn't at all ready for general consumption, but it's probably worth pointing out that it exists and is getting better and better all the time.

Here's an example of how you currently use it:

#update these to match your monome's settings
monome_io_file = "/dev/tty.usbserial-m128-115"
monome_model = 128

#create table and add monome
table = Table.new
table.add_monome(:io_file => monome_io_file, :model => monome_model, :cable_orientation => :right)

#add flashing app
table.add_app(:model => 64, :name => "flasher")
table.connect(:app => "flasher", :quadrant => 1, :rotation => 180)

#add spinning app
table.add_app(:model => 64, :name => "rotator")
table.connect(:app => "rotator", :quadrant => 2)

table.start

The aim will be to support both the standard MonomeSerial protocol, and its own more advanced API which will support bitmap composition on multiple layers. My main aim is to allow myself to think at a higher level of abstraction - patterns rather than than individual lights.

http://github.com/samaaron/polynome
- CommentAuthortehn
- CommentTimeNov 27th 2009
@samaaron: wonderful project! how is the latency with ruby?
- CommentAuthornæu
- CommentTimeNov 27th 2009 edited
@tehn, I haven't started triggering samples or the like yet, but from my early experimentations it seems perfectly fine - in fact I had to slow the buffer refresh rate down (I'm sending frame buffers to the monome in a constant fashion) because it was sending them too quickly and I was seeing strange artefacts on the display.

However, it's very important to note that, unlike my previous (failed) attempt at a Ruby library (monomer: http://github.com/samaaron/monomer) I'm not doing any timing sensitive operations. All the audio and timing aspects of the project will be executed within SuperCollider. So, in this case Ruby is just routing the messages, and doing the right thing with the frames (rotation, placement etc.)

In fact, the most exciting part of the project is yet to come. I intend to hook my monomes through polynome up to some Clojure software that will in turn drive the SuperCollider server directly. Clojure is an amazingly flexible language that will really allow me to bring the language I use to describe these things to a much higher (and for me, nicer) level of abstraction.

I'll be using Jeff Rose's amazing Overtone library: http://github.com/rosejn/overtone Luckily Jeff also happens to live in Amsterdam right now so some interesting collaboration will certainly develop over time.

Oh, and finally, if all goes well, I might end up quitting my day job and turning this stuff into a research project at Cambridge University's Music department...
- CommentAuthorrobb
- CommentTimeNov 27th 2009
Oh, and finally, if all goes well, I might end up quitting my day job and turning this stuff into a research project at Cambridge University's Music department...

wow!?
- CommentAuthornæu
- CommentTimeNov 27th 2009 edited
@robb Yep, I'm being serious. I popped to see the head of the centre for Music and Science and he was very interested in my monome when I showed him. I want to further my research in communicative programming (seeing programming as a form of communication) by using a monome and various Domain Specific Languages to control/influence music processes.

I think the monome is one example of a new kind of music instrument whereby improvisation can happen not just because of audio feedback (the music we're creating) but through other feedback loops such as the display. To me, it's these extra feedback loops and the communication patterns between us and the music processes themselves which is really exciting.
- CommentAuthortehn
- CommentTimeNov 27th 2009
wow. that job sounds amazing. good luck!
- CommentAuthornæu
- CommentTimeNov 27th 2009
@tehn, thank-you. Although it won't be a job - I'd be giving up a salary to do this for a year. It might turn into a job, or it might not :-) Either way it should be an amazing adventure!
- CommentAuthorloopparty
- CommentTimeNov 28th 2009
I'd also like to see OSC routing to multiple applications in the next MonomeSerial. I just released an application over at this thread: http://post.monome.org/comments.php?DiscussionID=6464 that does just that. However, it would be cool to see this directly in MonomeSerial...
- CommentAuthorgriotspeak
- CommentTimeNov 28th 2009 edited
actually, all a program would need is a command to remove focus from that app. and a command to let it know it has received focus

once focus is gone, ms could essentially be a big switchboard.

mlr (1) sends mlr/unfocus

then you get ms which has lights on representing however many apps you have configured.

you press a button and that sends the app /app/focus which lets the app know it should update leds.
- CommentAuthorpeterkirn
- CommentTimeNov 29th 2009
I'm curious, is there a reason Java seems to be off the table here? I quite like Python, too; I'm just wondering.

It seems like basically what you want, generally, is --
1. a library handling serial support
2. apps that do whatever people need, built on that library, using a standard API to talk to the library

#2 can have your fancy GUI and OSC routing and MIDI translation and whatever nifty features you want.

Speaking for Java, there are open source projects (read: no need to buy a license) that can handle packaging up cross-platform installers. Java would also be ideal for bridging to other protocols and applications.

Is there a reason people feel a native library may be needed? If so, for C++, OpenFrameworks could be another way to go, just because it's a bit more lightweight than something like JUCE, possibly more focused on the essentials something like this would need.

feeds

monomeserial next revision