monome

Hi everyone!

I'm sooooooo close to ordering a 40h, but unfortunately the
search-function of this site doesn't work at all for me (tried Konqueror
and Firefox - no matter what I enter, I always get "nothing found".
strange)

I'd google for details of using monome+linux+pd/chuck, but it seems that
I should order fast before the last 45 pieces are sold... :)

So, if someone would be so nice to point me at the right source of
information containing details about getting it to work with Linux (e.g.
Ubuntu, Dyne:bolic, ...) I'd be very grateful!


Thanks a lot.
^Rooker

linux should be the easiest to get working in one sense, harder in 
another.

the ftdi driver is built in to the kernel. no downloading ftdi drivers!

at one point joe experimented with getting a build a serialio in linux, 
and it worked, but then some "niceties" were added to serialio, like 
unplug notification, which are os x specific.

this is one of the instances where a serial-osc converter written in 
python would be very nice.

the chuck and pd apps need osc input, so the serial-osc converter is the 
block in the road at the moment.

anyone have any suggestions?

also i apologize again for the forum, i was supposed to have time to fix 
it recently, and it was stolen by some 16x16 prototyping urgency. bah...

tehn wrote:
> linux should be the easiest to get working in one sense, harder in 
> another.
> 
> the ftdi driver is built in to the kernel. no downloading ftdi drivers!
> 
> at one point joe experimented with getting a build a serialio in linux, 
> and it worked, but then some "niceties" were added to serialio, like 
> unplug notification, which are os x specific.
> 
> this is one of the instances where a serial-osc converter written in 
> python would be very nice.
> 
> the chuck and pd apps need osc input, so the serial-osc converter is the 
> block in the road at the moment.
> 
> anyone have any suggestions?

in two weeks i will be learning python for a class and have to do a 
loosely defined programming assignment for it (i.e. i can pick it 
myself). if all goes well, i will be able to post the results on friday. 
hopefully i will be able to implement orientation and prefixes like 
MonomeSerial. if not, there are always future versions =)

Thanks for the startup-info (and thanks for the hint that it's the forum
and not me who's broken :) - although I was too stupid to figure out how 
to reply <b>without</b> quote ) - The most important answer was indeed
"what about the driver".

I'll read myself into the serial-osc converter problem you're describing
(sounds like there's some programming work to do) - since I'm a coder,
maybe I can help.

(Already ordered my 40h - I just can't wait to use it on stage!)

1) I'm really too stupid to reply without quote. sorry.
2) Whoopee! My monome 40h came today.
Poor me is trying to "talk" to it using Linux-only. Since I'm constantly 
running into problems, here's my cry for help (please...?)


- Can't compile serialio. Lacking: IOKit and CoreFoundation - which seem 
to be libraries from Apple's darwin project. I didn't even try fetching 
them, since I'm only expecting more errors, cause I'm working on a PC. 
;)
Is it even possible to compile serialio on a PC running linux at all?

- I was so desperate that I even tried running serialXP and serialdotnet 
using wine (and mono), but mono chokes on the .NET code of these 2 
programs, so: no success. (Probably wouldn't have worked, anyway)

- So I said to myself: I'm not going to sleep before I haven't toggled 
at least one button. So I went directly for /dev/ttyUSB0. Strangely, 
"cat /dev/ttyUSB0" stays mute when pressing buttons on the 40h, although 
the 40h is properly sending data (tested that using minicom).
I've seen that the 40h should register itself as "/dev/m40h*****" 
(****** = serialno) - is that Mac-only?

Some errors in dmesg made me think that there might be a problem with 
serial-settings of this device (baud, bits, flow-control... ?) - Any 
hints would be greatly appreciated.


After some googling, I'm get the strange feeling that I'm the only 
person using the 40h under linux?


Thanks for any help.
^Rooker

***************
update: Finally, with gtkterm's hex-view feature I was able to 
communicate with the 40h on a serial level. In case someone cares: I've 
prepared the commands in separate files, using a hex editor (eg. hexer) 
and then hit "Ctrl+R" in gtkterm (=send raw file) and "boom" - I drew my 
first diagonal line on the 40h.

Finally, I can go to sleep now.

congrats! you're really on the frontier, i must confess. and
reply with quote is broken, so it's not you by any means.

i need to change that text in serialio, about being linux compile-able.

it's definitely no longer the case. a very early version, without a lot
of os-x niceties, worked in linux.

i'm hoping that a python/ruby/etc API will surface soon that addresses
the serial port directly, which will be truly cross-platform.

one thing you could also try, is that pd can probably load
_40h_serial.mxb from the max/msp base patches. not sure how the serial
object works in pd, but it should be able the same.

please continue to share your experiences on linux, i'd like to make an
effort to develop some documentation and see if we could funnel some
programming time into making it more clear.

Frontier.... hm? Roger that.

As far as I've seen in the serialio source and the docs about the serial 
protocol of 40h, I'm feeling eager to either port serialio to linux - or 
write "jerialio"? (Sorry, but of all programming languages I know, Java 
is the least rusty one in my head - so I might be able to write 
something useful quite fast - and be cross platform).

Something I'd need to know before I start:
Since I've never seen serialio or serialdotnet or serialxp or monoserial 
in action, I'm not quite sure which features they provide. My first 
steps would be to simply map the serial commands to OSC.
(Haven't found any "official" OSC lib for java, but maybe 
http://www.illposed.com/software/javaosc.html is sufficient?)

Wish me luck - I'm going in.

serialiodotnet and serialXP should *possibly* work in linux, without 
need of compiling, with mono, which is the CLR (the .NET runtime engine, 
like the JVM for java), on linux.  the problems are that i have some 
windows-specific stuff, like registry support, in serialiodotnet. 
serialXP might work, which would be even better, although honestly i 
dont know how well apps translate over to another OS, and that was never 
an aim of mine, mainly because i dont have a linux install/machine to 
work with, nor have i ever used any form of linux.

might want to check this out:

http://tekrat.com/wp/monome/

also, in my hazy memory, there was a java-serialio project underway, 
about a year ago, and it seems that it didn't get finished. also this 
forum has the clunkiest search capabilities, so it's not very helpful 
unfortunately.

alternatively, doesn't processing run in linux? there's a processing 
library for the 40h, and for osc, which should get you there quick?

also, if anyone needs any help programming OSC, do ask.  i think liblo 
should work/help if you are using C++/C, but in other languages - ive 
done my own OSC-parsing/creation library for C#, and i can def give any 
pointers on how to do one yourself.  its very easy, though.

http://jklabs.net/monomic/ is the 40h library for processing that i 
think brian was talking about. i downloaded it the other day, shortly 
before i remembered i don't know what i'm doing, so i haven't used it 
yet.

i'm told processing is very similar to java - can anyone confirm? i 
don't know if rooker could make what he needs in processing or not. 
would be sweet though.

First of all: Thanks for all your infos and support!

@kid-sputnik: I did try running serialXP (and serialdotnet) using Mono - 
but as I've mentioned above: It choked, and I suspect a Mono problem 
(Some font missing. Probably trivial - but it was late and I didn't want 
to waste time on a possible dead-end)

@tehn & stephen:
processing... hm...
I've worked with it one year ago - and it is indeed very java-istic (and 
simple), but it for my taste is was not general enough - too 
art-focused.
You can do visual stuff really quick (even 3D), but I'd like to make 
something small and general - just like serialio/mono_serial was/is, so 
that people can choose the "high level" app themselves - using OSC. Just 
like it is on MacOS and Win right now.

... but: I went for python. Why?
Since I'm planning to use pd, I'm planning to use "gripd" 
(http://crca.ucsd.edu/~jsarlo/gripd/) in order to have some better GUI - 
And because gripd's partially in python, I thought: "Hey! I always 
wanted to take a look at python!".

So I did.

I've spent the whole day reading, reading and reading - and so far I've 
ported the serial-messaging functions from serialio to a python module.

There didn't seem to be any serial- or OSC support in the basic libs, so 
I went for these:
http://www.ixi-software.net/content/body_backyard_python.html 
(SimpleOSC)
and
http://pyserial.sourceforge.net/

I tried to stick to the original serialio namings as close as possible - 
so here's an example of my current "hello-world-cross" on my 40h:

------------------ test.py -----------------------
ser = serial.Serial('/dev/ttyUSB0', 9600)
msg = Message40h()

cmd = msg.messagePackLedRow( 1, 0xFF )
ser.write(cmd)

cmd = msg.messagePackLedColumn( 2, 0xFF )
ser.write(cmd)
-----------------------------------------------------

About OSC:
@kid-sputnik: I'll probably get back on your offer to help with OSC 
implementation. ;)
Currently I'm trying to improve my python abilities and make the 
serial-side clean. As soon as that's done, I'll add OSC.

btw:
I'm sticking to the references in 
http://wiki.monome.org/Attachment/MonomeSerial.txt - is that ok?
Or is there any better definition of the current OSC protocol of the 
40h?

thats what im working off of now, with help from brian.  originally i 
just did the serialio commands, which are easy.  the monome serial stuff 
added on is much more complex, basically because the osc commands can 
now change the state of the app itself - there is a subgroup of commands 
with the prefix /sys that can be used to change the values of monome 
serial - like, /sys/prefix or /sys/cable, which actually change the 
settings of monome serial.  personally, i LOVE this idea, but it 
requires alot more work (especially in GUI-based apps, in command line 
it would probably be much simpler, for obvious reasons (my initial 
serialiodotnet should have been commandline probably, but its hard to 
resist doing GUIs in .NET, since the designer-mode makes it so easy to 
get started).

commandline... I like commandline!
(but I guess that's something that people think about linux users 
anyway, right?)  ;)

However:
I just wanted to take a look at monomeserial source - and I can't find 
it!
The monomeserial-0.9.tar.gz seems to contain only the binaries. If 
someone could hit me with a large trout pointing me into the right 
direction, I'd be grateful.
thanks.

sadly the monomeserial source was lost when joe's macbook died. luckily 
he's almost done recreating the whole thing.

i'd say working off the monomeserial.txt as a reference is the best 
approach, as you're doing.

also it seems you found all of the best python references, exactly what 
i looked into doing myself until i had absolutely no time to delve into 
it. i'm really excited about pyserial, and hoping that it can all be 
cross-platform in the end.

i'm going to agree with you on command-line love. command-line plus and 
interactive terminal would be glorious... typing in strings to send 
would be great.

also i haven't looked into gripd, a gui-extended pd is definitely a good 
thing.

glad to have you guys here!

Now that you mentioned the "lost source", it popped back up in my head 
that I've read that before here in the forum. So I'll stick to 
serialio's source for the time being.

Unfortunately, things are taking longer than they'd have to, since I'm 
learning python while writing the all new and shiny "serial-pyio". :)
Now that I know how to create packages, modules and classes (almost 
properly), I'm close to finishing the serial connection side (Quite some 
progress for a single day of work... - *tapping myself on the shoulder*)

About the outcome:
- commandline: of course.
- interactive terminal: I'm tempted to prepare some initialization for 
the python shell - and use that as interactive terminal. With proper 
initialization and the right front-end-functions it should work just 
fine (+adding scriptability: "monome-python-fu") - What do you think?
It's not that I'm lazy, but isn't the GNU way: "Wait! I think someone 
has already done that... Let's use/improve it"?
- GUI: As far as I've read, GUIs should be quite possible with Python. 
Since it's only gonna be some simple frontend, maybe I'll put that on my 
list, too! (If I do, I'll just copy MonomeSerial)


PS: I just saw that there are 2 functions for drawing a row/column in 
serialio - and one offers an additional parameter "length". The code 
looks like it could swallow a serialized bitmap, displayed line by line 
- am I right?

i'm actually not sure what the "length" parameter is about.

in monomeserial, we extended /row and /col so that if you specify 
multiple bytes, they're tacked onto that row.

so /row 0 255 255 255 255

would specify 32 lit on the top row.

we also added /frame which is 8 bytes, so a full 8x8 bitmap.

unfortunately this may have been shortsighted in the design, as i'm not 
sure how we're going to adapt the formatting for the 16 x 16.

bah!

> unfortunately this may have been shortsighted in the design, as i'm not 
> sure how we're going to adapt the formatting for the 16 x 16.

i just assumed <row> byte byte

@tehn:
When you say "32 lit on the top row", you would need multiple units - 
Serialio seems to be meant for handling multiple 40h connected to the 
same computer, although there are some things in there which look more 
like serialio is half-hardcoded to 1 or 2 devices.

My current approach is to have a class for each device - and a wrapper 
class which can handle multiple devices as some sort of button-array.

I'm not really comfortable with the way it was done in serialio... And 
I'd like to make it 100h compatible, too - or at least easily expandable 
(something like "class 100h(40h)").

Something else I was wondering is if it's possible to query the 40h for 
the state of a certain led? This would make toggling possible.


@kid-sputnik:
2 bytes? Are you talking about 100h compatibility or 2x40h ?



------------------------------
Generally, I was tinkering about how I could "beautifully" handle:
 - multi-device
 - 100h compatibilty
 - individual device orientation (plug = where?)
I'm thinking about using 2D matrix transformations to handle all of them 
at once (and for number of buttons). I'm not sure if it ain't overkill, 
but handling it manually (switch/case blocks for each direction) just 
seems so wrong!


Right now, I'll leave the multi-device implementation aside for now - as 
well as the ability to rotate the device - and will start the OSC side.

i meant for the 100h.

for the new serialXP, to impliment multibox support, what im doing is 
just making a Box class, and then making an array of them, one for each 
instance of the FTDI driver with a m40h or m100h serial number 
(autopopulated by reading registry entries, in linux you can do whatever 
is done for OSX/monome serial i imagine).

also, for toggle controls - i just make a toggle-control in reaktor or 
max or whatever, whose state is changed via a press, and then the state 
of the toggle control (just an on/off memory state saver) determines the 
led.  basically, there are software controls, the buttons alter them and 
the leds reflect their state visually.

i dont think the box has any concept of state, at least as far as what 
the user can access.  even determining what buttons are held takes some 
work - like, for a sampler where a row triggers slices fo a sample, you 
want the sample to play as long as any button in the row is held.  so, 
you have to store button-presses, since releasing any button gives a 0 
and if you just go by that, the playback will be all wrong.

we considered doing internal state saving with monomeserial, but decided 
that was possibly more the responsibility of the individual program.

for multiple units, i believe the method in serialio is dated and 
clunky. joe completely reworked it (elegantly) for monomeserial. he 
should be done with the source soon, so we can stop guessing about it.

basically multiple units is handled by implementing "offsets" which 
catch different ranges of leds, and send shifted values for key presses.

so an /offset 8 0 would shift the whole unit to the right 8 steps.

this makes sense, as a second unit, to create a seamless 8x16. paired 
with orientation control, it's pretty dynamic.

this is where multi-byte rows come in, etc.

i'm not sure how joe handles it, but i used simple lookup tables for 
rotation. there are some simple equations you could use, but it seems 
pretty efficient and fast to just use that small chunk of memory.

@kid-sputnik:
Your array-implementation sounds pretty much like my plan, but how 
exactly would you handle something like this:

12
3

where 1,2 and 3 are 40hs - Where in your code do you do the splitting of 
bytes? (=which row/col/led is on which device?)


@tehn:
The offset part is perfectly clear for me, but I'm just not sure "where" 
(logically) in the code the handling of this should be done. I'd say: a 
class instance for each device and then a wrapper-class (like 
kid-sputnik's array) for addressing them.

i do offsets and orientation in the Box code, at the press methods and 
the led/led_row and led_col methods (frame just calls _row x8, so that 
doesnt need it).  for orientation switching i did what brian suggested 
and made a sort of lookup table - its a static method that accepts a 
byte, and returns the byte with flipped-bits.  i dont flip the bits in 
realtime, as that would be alot more costly, i instead make a table of 
the flipped bytes (static, so its done only once), and use this to 
lookup the new led_row or led_col values.  for led its much simpler, i 
borrowed the code from a user here (see my thread orientation in the 
modifications forum i think).

about making an array of box units - i dont even consider their 
position, actually.  i let the user do that, by messing with orientation 
and offset values.  if you want, you can keep each box with 
cable-orientation = left, and offset x and y = 0, and they will pretty 
much just be 2 identical units (useless, but possible).

brian and joe came up with this method for monome serial, and i 
personally find it brilliant.  often times its tempting to add alot of 
built-in functionalitty to the "serioalio"-style app, like state-saving, 
but as brian said alot should be left up to the music-app developer, 
this gives them alot more freedom.  personally, in reaktor there are 
alot of things i cant even do because i cant send strings, but i do use 
max as well and im glad that the monome serial spec allows for such 
flexibility (like, programmatically chagning offsets, prefixes and cable 
orientations INSIDE of that Max/MSP or whatever app!).

no, no...
I do have cable-orientation and x/y-offset stored for each unit, but 
when multi-unit commands are sent (e.g. setRowState 0 byte byte byte), 
the function code for each unit would receive all e.g. 3 bytes and then 
pick out which ones are for itself.
I was just suggesting that this should happen (on code level) outside of 
the individual class-instances for each unit. I guess I'll just attach a 
few lines of code to my next msg to clear things up.

Sorry for nagging! ;)

Damn full time jobs... You never have time for the really interesting 
things. This evening, I've added the first framework of OSC support and 
I've successfully tested it in both directions.
(Well, it actually crashes when I press a button on my 40h - but that's 
more or less on purpose. I was too lazy to fix a prefix for a function 
that's in another module).

In case someone's curious to see the messy pieces of code I've produced 
so far, feel free to take a look inside 
http://entenhausen.at/~quack/UNI/m40h_development_12May07.tar.bz2

Don't worry... I'll clean it up and give things good names as soon as it 
works.


Good night.

> sorry for nagging!

no, thanks for sharing!

^_  that was me up there, sorry!

Yeeehaa! I've just tested fully operational 2-way communication with 
/40h/press and /40h/led, by writing a 5-liner sending random 
col/row/state messages over OSC to serial-pyio.
...Unfortunately, I've never seen the 40h running on Windows or MacOS, 
so I can't compare the performance. It seemed rather slow, but that 
might also be because of a lot of "blanks" drawn by "randint".
Afterwards I tried letting a single LED blink in rather high frequency - 
I guess it still is fast enough.
Anyway, I'm currently adding the mapping of all OSC commands known to 
me.


Now some questions about some functionality:
1) "+ clear
/40h/clear [state]
state: 0 (off, default if unspecified) or 1 (on)"

I thought that "clear" will turn all LEDs off, but where's the 
difference between "clear off" and "clear on"?

2) + shutdown?
What is shutdown state? I've tried sending that to the 40h, but nothing 
happened.


3) ADC related messages seem to be missing as OSC commands in 
"MonomeSerial.txt":
/adc_enable
/adc (=read value)
...and I presume they should expect a unit-index as well:
e.g.: /adc_enable 0 1 (enable adc1 on device0)


So right now I'm beautifying my single-unit code and then I'll add 
support for device-orientation.

I'm alredy enjoying "Conway's life simulation" running serial-pyio!

Tataaaa!
(And is there any help regarding the wiki-syntax for changing a site in 
here? I did some brute-force formatting on the conway-life-app-page. 
Syntax seems somewhat mediawiki-like)


I guess that's it for today. I'll go and play God with some led-bacteria 
now and then I'll go to sleep.

good night everyone.

that's bizarre about the perceived latency. i've always felt it's 
incredibly fast.  we should devise a quantitative method to measure this 
across platforms and APIs.

1. clear. basically "clear" could mean "all off" (default) or "all on"

so /clear 1

would turn everything on. sometimes this is helpful.

2. shutdown disables the led driver. not really useful, leftover from 
debugging. can be used for off-blinking while saving the previous state. 
a sloppy hack, if you will. just like /test for on-blinking while state 
saving.

3. adc stuff isn't implemented yet in monomeserial, and there are some 
issues with prefix sharing and offsets, etc, so i'll have to give that 
some design-brainpower soon.


wiki is sometimes clunky with its syntax, see here:

http://wiki.monome.org/view/HowToUseThisWiki


glad to hear everything is working out!

Ok. I revoke what I said about speed!
I just wrote myself a small little program that lights a single led 
across the board:


# Speed-test:
poll_wait = 0.2
while not(_exit):
  for i in range(8):
    for i2 in range(8):
      c = stdscr.getch()         # Check for keyboard input:
      if c > 0: handleKeys(c)

      (col, row, state) = (i, i2, 1)
      monome.osc.sendMsg(MSG_LED, [col, row, state], host, port)
      time.sleep(poll_wait)
      monome.osc.sendMsg(MSG_LED, [col, row, 0], host, port)


Starting with a pause of 0.2 seconds between turning the current led on 
and off, I'm using keyboard left/right to decrease/increase this pause. 
I've decreased by 1/8 of its current value, in order to get smoother 
results as the number becomes smaller.

It's like setting the speed of an old record turntable, using those 
"running dots" on its border (except that the pattern on the 40h is not 
becoming steady):

- First you see the led "running", but in the end it looks like a whole 
row is updated at once, running across the columns. Then I've output the 
current pause-value in order to get a measurable value.

Today's version:
http://entenhausen.at/~quack/UNI/m40h_serialpyio_13May2007.tar.bz2

It already supports multiple devices (regarding prefixes & 
serial-ports). I had to modify the "simpleosc.py" module in order to 
allow dynamic change of prefixes.

Still missing (=TODO):
- unit orientation
- x/y offset
- usability

> Still missing (=TODO):
> ...
> - usability

ahh, usability is so overrated these days!  =P

rooker, i just e-mailed you. contact me at tehn@monome.org if you don't 
receive it.

rooker wrote:
> Damn full time jobs... You never have time for the really
> interesting things.

This is how I feel about school. I would have finished pLayer AND 
nibbler by now if I wasn't in school.. Stupid school...

hey, if you worked my dayjob you'd be begging for more calculus 101! 
its like slow torture, but less dignified! (yes, its retail!)

i wish i was studying integrals and related rates, but nah,


we got exact d.e.'s and sytems of em.

homogeneous and non. and nand, nor and enough finite states to make you 
wanna hit the bon(g)..





couldn't make it rhyme.. bummer. late night. just got home. time to pass 
out.

goodnight forum.

school...   *sigh*....

Those were the days when I really had a shitload of time - although I 
wasn't aware of it back then. I mean: it ended at 1pm  - and the rest of 
the day was free!!! (homework was usually made on the morning of the day 
it had to be done. :) )

So beware of full-time jobs: If you don't need them, and you earn enough 
to avoid them - do so! For a well-paid IT-guy, 3 days a week should 
usually be enough to afford a living.

yeah, i'm doing IT right now (work AND school... they really get ya by 
the balls)

but it's either that or a shitton in student loans..

the computer engineering major eats up all of my time though...


funny, because i know that i'm going to be looking for a job that will 
pay me 40,000/year after taxes with a maximum of 30 hours per week. 
(probably NOT an engineering job...)

these are the days though, right?

In order to compensate the frustating part of coding the serialpyio just 
in order to find out that I can't run *any* of the MaxMSP patches in 
Linux, I wanted to see my 40h in action - at least once - with 
ready-made stuff. So I booted Windows.

well... Windows 2000.

Which means: No MaxMSP for me - at all! *aaarrgh!* Those bastards put a 
OS-version-check into their installer! Why are they doing this?


The good side of this, however is, that I had the chance to test 
serialpyio in windows - and guess what: It's running fine!
(The only additional thing to install is "win32api for python" to access 
the serialport)

Any chance that I could port the 64step or mlr to pd?
(Is there something like a clear-text export for msp patches?)

i dont think its super easy to port that pathes, but its possible.  some 
patches might work perfect in .pat form if the externals are the same, 
but im thnking mlr wont be that easy.

mlr uses a lot of max/msp specific objects and won't port easily to pd, 
unfortunately.

have you tried out any of the chuck patches?

david's pd patches are very nice, but often complicated (he's a 
complicated guy)

just wanted to drop a short note that I'm still working on it
- but last week I was in Africa and thus not really able to make any 
progress here.

I'm currently doing some final tests on the basic functionality (setLed, 
getButton, rotate, changePrefix, etc...), but so far everything seems to 
be working fine.

Since I was too lazy to set up a CVS server on my own, I decided to make 
"serial-pyio" a sourceforge project 
(http://sourceforge.net/projects/serial-pyio) and if everything goes as 
planned I'll release the first version (commandline-only  for the 
beginning) in the next few days.

Although there's no release package made yet, it should be possible for 
anyone to retrieve the latest version from the CVS.


--------
One thing I could use some help with:

- I want to get a list of available serial ports in Python. I know that 
this will be OS specific (so I could test it on Win and Linux), but I 
can't find any clean solution for this on the web... So I'd be grateful 
for any hint.
(and *no*: I won't accept "ls /dev/ttyUSB*" as a solution. ;) )

really excited to see this! great work.

i'd consider e-mailing the ftdi support people about cross-platform 
detection. daniel found some way by querying the registry in xp, i'm not 
sure how joe does it in os x.

ftdi has been quick in the past.

thanks for blazing the trail in linux. i'll help assemble some 
documentation.

for linux, shouldnt device serialnumber querieing be similar to that in 
OSX (UNIX)?  correct me if im wrong.  i know monome serial is in 
C/C++/Objective C, but the method that is used should be do-able in any 
language. i think for OSX, the data is stored in a file where the FTDI 
info is.  as brian said, its differant for Windows, for Win the info is 
stored in the Registry (let me tell you how excited i was when i 
realized this -> thats sarcasm!).

i got the info on the registry entries needed from the FTDI FAQ on their 
site, id check that out as im sure there are similar entries for 
unix/linux/osx etc (im also thinking thats where joe looked to find 
where to search).

Thanks for the hints about the serial-device. Let's see how far I'll 
get.

I wanted to test serial-pyio with Max/MSP in windows, but I couldn't 
find any OSC settings for the 64step patch?
(Maybe I should check the forums for info about that...)

However, I want to release a useable commandline version now (as my next 
step), before I start reading myself into how to make a GUI in python.

64step listens for OSC on port 8000 and sends on 8080 to localhost.

simple messages only are used.

/box/led
/box/press

and maybe

/box/led_col
/box/led_row

also make sure you have the most recent version of max/msp. they changed 
their OSC objects several months ago.

i'm really excited about your project, thanks for the dedication!

is python a scripting or compiled language?  do you need a runtime 
engine?  just curious, because ill test it out when its up, just not 
sure what i need.  i SUPPOSE i can google!  =)

@kid-sputnik:
Interpreted (although it compiles some of its files on runtime). For 
windows you need to download the windows version of Python 
(www.python.org) and pywin32 (sorry, don't know the exact link, but I 
found it right away, so I'm sure you'll find it too!).


However:
I've improved some documentation (= added a README.txt), beautified some 
code, fixed some minor things and commited all that to the repository.

Couldn't test it thoroughly, because the site was down today and I 
didn't have a copy of processing/game of life anymore locally (That's 
the only thing that I can run on linux....)

So, as I've mentioned above it's in the CVS on sourceforge - ready for 
testing! (if you want to?)

Will pack a release as soon as I have done some testing with other 40h 
apps.
Currently it's commandline only. My plans are:
- Add a "shell" like interface by abusing the python shell. :)
- Will add some GUI (can't be too hard, but I have never ever done any 
GUI stuff in Linux before...)

*sigh* - Today I've really learned that this is my FIRST python program, 
my FIRST sourceforge project and my FIRST cross-platform application...

That adds up to something that works, but is not too beautiful (for 
now). However, I've managed to set up the right files for release on 
sourceforge (no need to CVS anymore):

http://sourceforge.net/projects/serial-pyio/

(I've uploaded the files as .zip, .gz and .bz2)

i'm really excited to dig into this. you're laid out a framework for a 
lot of exploration for a lot of people. thanks!

hey guys,

just wanted to throw in here that i've successfully used the monome 
under linux using a java version of serialio i wrote awhile back.  i got 
a bit discouraged because i couldn't find any decent serial 
communication libraries that were free (the one i ended up using had 
some bugs and sends phantom presses once in awhile, i dont remember the 
specifics right now but i traced it back to the library itself, and i 
couldn't figure out how to fix it).  there may be a decent library out 
there now that this code could be retro-fitted to use.  anyways, here's 
the latest version of the source code, hope it helps!

http://www.post-digital.net/~phortran/serialio-java.zip

tom

just realized that the actual source code isn't in that zip file, you 
can find it here:

http://code.google.com/p/jserialio/source

or just

svn checkout http://jserialio.googlecode.com/svn/trunk/ jserialio

tom

@Tom: I've also considered using Java at first, but I got discouraged 
because I couldn't find some proper serial and OSC support.... :)
I took a quick look at your code, and I really like your approach of 
having a separate listener class for each event.

Which audio application have you been using the 40h with in Linux?


@Tehn:
I'm really sorry that it's not "prettier" yet, but I really gotta start 
taking care of the musical applications now or my band members will kill 
me!

I've shown them the 40h demo videos, so they've got some quite high 
expectations! - I'm currently evaluating which application to use in 
Linux, but I'll probably stick with pd (because I'm afraid of dead-ends)

hey rooker,

i had only used linux to test that it actually worked, which i believe 
it did (it's been over a year).  i'm mostly using max/msp with the 
monome (although have had successes with reaktor and vvvv, which is kind 
of like jitter).  i'm also using it with my machinedrum (via max/msp) 
and it works great, but again, all windows-based.

java has pretty slim pickings for serial support unfortunately, i ended 
up with this rxtx library which mostly works, but has a few flaws.  OSC 
support wasn't too difficult to find, and the OSC library i used is 
included in the svn repo.  i'd love to see somebody fix the shoddy 
serial support but am not holding my breath. it's entirely possible that 
a new version of the library is available with some of the issues 
resolved, but i haven't really looked into it (serialiodotnet works 
wonderfully for me).

tom

I haven't followed this whole thread, one basic question:
Does the monome now work with linux (such as ubuntu), using either 
serial-pyio or jserialio?

And this would be enough to send OSC messages to and from Pure Data?

That would be really great.

@jah:

Yes, the monome can now be used with Linux (and all other platforms 
running Java or Python)

Although it might sound non-objective, but I'd suggest that you use the 
Python implementation (serial-pyio). Not because I wrote it, but I saw 
some flaws/bugs in tom's jserialio (e.g. cablepos not properly 
implemented, unreliable serial transmission (as he said himself)) - and 
I guess it's not maintained any longer - but choose for yourself!.
btw: Serial-pyio was developed using (K)Ubuntu Dapper/Edgy.

Regarding pure data:
I'm still working on creating a proper Debian/Ubuntu package for 
pd-extended, because Hans' pdext-installers 
(http://at.or.at/hans/pd/installers.html) seem to be 32bit only - so I 
can't personally confirm that it works.

but: I've tested serial-pyio with "game of life (processing)" - and it 
works perfectly.

I'd be more than happy if you would give it a try with pd (I sure will, 
since that's the next step on my roadmap: Writing pd audio-patches for 
the 40h)


If you need any help (or find any bugs), I'll do my best to help.

thanks for the info, rooker.

i'm currently running ubuntu in vmware in win xp, and i've successfully
been running Pd there. for serious work i'd of course need ubuntu on a
separate partition from win xp, with lower audio latency. i have no idea
how to get low latency (asio-like) in linux. i've heard i need to
recompile the kernel to get this, have you got any idea of how to do
this?

I haven't done any latency tweaking yet so I honestly don't know, but 
from my personal experience, Linux' audio latency is usually excellent 
out-of-the-box. My suggestion is that you just try and see if it's 
sufficient for you, and only worry about it if it ain't.

If I got it right, "http://lowlatency.linuxaudio.org/" says that the 2.6 
kernel should be low-latency already without patching. They just suggest 
a few other tweaks.

If you're planning to connect several pieces of audio programs together, 
I can recommend "jack" (http://jackaudio.org/). It's a low latency audio 
connection kit. Awesome.
Just yesterday I've modified a drum machine patch so that I could send 
the individual parts (bassdrum, snare, ...) as separate tracks to 
ardour.

btw: *the* most complete collection of linux-related sound links can be 
found here: http://linux-sound.org/

> I haven't done any latency tweaking yet so I honestly don't know, but 
> from my personal experience, Linux' audio latency is usually excellent 
> out-of-the-box. My suggestion is that you just try and see if it's 
> sufficient for you, and only worry about it if it ain't.

I installed Slax on a USB stick yesterday with the Pd module and, yeah, 
latency-wise it worked extremely good out of the box (lower latency than 
XP w/ ASIO). No latency tweaking needed there! :)

There's something strange going on with the graphics in Pd with this 
slax installation, though. The "close window? (yes/no)" window appears 
behind every other window. So when I want to close a window I have to 
click close (X on window bar), then minimize it and most other open 
windows (!) to be able to click "yes". Extremely annoying. Also, the 
font in the object/message boxes is too big, making it hard to read. 
Perhaps this is a tcl/tk issue. I'm gonna try to get ubuntu running on 
the usb stick instead, Pd seems to work better there.

have you tried puredyne? ( puredyne.goto10.org/ ) - i burned a CD of it 
just to see if i could run it on my 333mhz AMD K-6 laptop (the answer is 
no), but you might have more luck on a newer machine.

hi stephen,

yeah i've tried pure:dyne on a live cd, it boots up but wasn't able to 
recognize my audio card. i'm pretty bad at linux hacking, so fixing a 
soundcard issue could take some time i guess. that's why i tried damn 
small linux first and then, successfully, slax. slax found my soundcard 
right away.

i'd love to use pure:dyne, looks like it has everything you would need 
for music/media production.

my plan is to have a music and pd-optimized linux distro on my 4gb usb 
card. slax is ultra-fast on it, i hope ubuntu is gonna be when i try it 
out on usb. i really want to get into jack also!

As far as I know, pure:dyne is derived from "Dyne:bolic" 
(www.dynebolic.org), so it might be worth a try, too!

@jah: About your soundcard problems: Which soundcard do you have?
My plans are also going towards audio-distro-on-a-stick (Cause I'm 
pissing my pants before every gig that my notebook/harddisk suddenly 
dies....)

What are you going to use the monome for? Maybe we could collaborate.

i use the monome for music production, not gigging really :) i mostly 
use my builtin soundcard (in my thinkpad t43), but i also have an echo 
indigo io. if i could get the builtin soundcard to work with pure:dyne i 
would be very happy, looks like a cool distro.

@rooker:

i tested serial-pyio with win xp now, i get this error when i run 
"python serialpyio.py /dev/ttyUSB0" at command prompt:

'Cannot open "/dev/ttyUSB0"'

mark hammond's win32all is installed. i've tried with /dev/ttyUSB0 to 9, 
nothing works i'm afraid. "/dev/ttyXXX" sounds very linux-like, should 
it be like this on xp aswell? :) the monome works fine with the .net 
monome-serial.


EDIT: my monome also works fine in max/msp using _40h_serial. according 
to _40h_serial my monome is on port COM 2.

About the /dev/tty/USB0 problem:

Windows doesn't have its devices in the filesystem, thus simply start it 
with the corresponding COM port:

"python serial-pyio COM2"

(Sorry, but currently you must figure out for yourself which virtual COM 
port the monome registers itself at) If there's anything else unclear 
even after reading the docs (=the README) of serial-pyio, please tell me 
so I can improve it.

btw: Which soundcard have you got in your T43?

rooker:

thanks for the help! i got serialpyio to connect to my monome on the 
com2 port now (win xp) - but for some reason button press messages dont 
seem to get sent over osc!

the test (serialpyio -t argument) runs fine with lights and all, and if 
i send "/40h/led 0 0 1" to port 8080 the top-leftmost light is lit. 
sending "/40h/led 0 0 0" and the light is shut off. so osc seem to work 
when sent to the 40h to control lights, but not from the 40h to get 
button press feedback! any clues on why?

in win xp, the soundcard of my t43 is called "SoundMAX Integrated 
Digital Audio", manufacturer: "Analog Devices, Inc."


EDIT: by the way, the readme.txt actually says "python serial-pyio 
/dev/ttyUSB0" also in the win32 example. perhaps you should update this 
so it says "python serial-pyio COM2".

Thanks for the info about the README. I'll update it ASAP.

About the OSC problem:
Since the communication is bi-directional over different ports, please 
check which host/port your application is expecting (serial-pyio should 
display its default OSC settings on startup) - ports 8000 & 8080.

hey, rooker, is there a way to do a C-style "#if _WIN32_" in python? 
just wondering, because if so you could add code to find the serial 
number.  you are right, its not in the normal file system, its in the 
registry, buts its pretty simple to get at, since FTDI drivers are 
always installed in the same place.  its pretty easy to find via google, 
although i can post it if you want (gotta dig it out from my code).

of course, im not trying to be pushy or anything, i know this is all a 
labor of love and mainly for linux users!

@kid-sputnik:
1) Yes, I can fork code internally based on the OS it runs on - I've 
already written and designed it so that some OS-specific quirks can be 
implemented "the right way".

2) I've already written an email to FTDI, asking for details how to 
detect their devices. They've answered my quite quickly, but I haven't 
had the time to implement it yet. (as mentioned above: I gotta get going 
with the musical side, because so far, I haven't made a single "beep" 
with my 40h... was busy writing serial-pyio)

3) It's actually not mainly for linux users... If it's got a GUI and all 
the "niceties" of MonomeSerial, it might be worth considering having one 
solution for all platforms. Don't want to sound megalomanic, but it 
would save us all a lot of time and resources.

btw: I've seen that it's possible to produce standalone python-scripts 
as binaries (for Windows) - it's called "py2exe" 
(http://www.py2exe.org/)

I've checked the problem Jah was describing (button presses not 
recognized), and he was right! A small error slipped in while cleaning 
up some class code... This caused the function responsible for reading 
message from the serial device to expect messages with 0 bytes length.

Sorry... as I said: This is my first Python script! :)

This should be fixed now, and I've put the new version on sourceforge 
(v0.1.1)

Rooker: thanks for looking into this. Im away from my computer right now
but will try the update when i get back home. I really appreciate your
effort in learning python and creating serialpyio so we can have a true
crossplatform serialio! Keep up the good work.

Thanks for the slap on the back.

I'd like to say that I'm doing my best, but actually due to lack of time 
and my need to focus on the music side now, I must prevent myself right 
now from working too much on serial-pyio.
(I'm not too good with multi-tasking....)

There's still a lot missing to make it comfortable, like:
- a proper installer
- GUI
- configfile
- Docs: Installation HowTo, Good API docs, ...

The sooner I have a working pd patch solution, I can continue to improve 
serial-pyio.

installers and gui's are overrated ;)

thanks for the great work!

> Don't want to sound megalomanic, but it 
> would save us all a lot of time and resources.

being as Joe Lake's MonomeSerial/Serialio code is VERY tied into the 
actual device firmware code, i kinda doubt that brian will stop 
considering joe's monome serial as the main monome app.

thats not important though.  its awsome that you got the first truly 
crossplatform monome app going.  id check it out if i wasnt so busy at 
the mo.

actually i'm always open to better options.

what it comes down to is having monomeserial (for both xp and os x) be 
as easy to install and use as possible. if something else works better, 
again, i'm all for it.

think there's a binary converter for os x?

And now for something completely different...

While trying to focus on the musical side of programming now, I saw that 
PD could do Python with a certain extension installed. Since this is 
quite a tedious task on a live distro, I thought: What if I had could 
improve serial-pyio to have its own extensions?

So that one could write all that stuff that's cumbersome within the 
audio application, and what is not included in the standard commandset 
of monomeserial.
I haven't done all the thinking yet, but it would end up by having an 
"extended" OSC command set.


Examples I'm thinking of are:
a) state handling of a sequencer.
- '/40h/seq/clock 1' could increment the audio position pointer-row.
- '/40h/seq/row 1 0 0 0 1 0 0 0' translating it to the proper row 
byte(s)

b) sample playing
- '/40h/smp/row x pos length', calculating the right led to show the 
current playcursor position
...
...

Maybe I could use this mechanism to add mapd functionality, too.


It would be nice to have feedback on this, since you know: Whenever a 
programmer thinks something is good, its always necessary to get a 
second opinion. :)

id have to see it in action, cuz im a bit dumb, but that sounds pretty 
cool.  is the idea that the user could add extensions via the GUI, or 
via their own python code?

Hello Rooker,

Hopefully you remember my post around ghost presses... So, the advice of 
tehn is to finish the button board. Probably the problem just comes from 
pins hanging at no level.

Anyway the code I used is something like the following:

In the test function of serial-pyio, I added something like, if you 
replace the:

for x in range(8):
  for y in range(8):
    device.setLed(ON)

If I replace the 8 by 1 no ghost presses.

I will come back to you when my button board is finished.

Anyway it really cool to have serail-pyio. I will use it to make small 
stand alone apps and games, will be fun.

I think it would be handy to have a clear separation between the 
communication with the 40h and all the OSC handling. So that when you 
just need to make a small app that just want to communicate with the 40h 
and no osc. I did not looked toroughly in the code, so maybe it is 
already made.

A simple console to send testing command to the monome would be great 
too.

As python programmer, I can help on these two aspects.

Julien

Hello Rooker,

I looked a bit into the code of serial-pyio. I have a couple of remarks 
to improve the code.

In the for loops construction like this:

for x in range(len(collection)):
  do_something(collection[x])

can be simplified to :

for item in collection:
  do_something(item)

As an example I rewrote two function in message_xxh.py:

def messagePack( self ):
  # Simply converts numbers to characters and concatenates them
  return ''.join([chr(x) for x in self._data])


def messageToNum( self, message ):
  """Converts a string (e.g. message read from serialDevice) to a 
numerical sequence
  for later processing.
  """

  return [ord(x) for x in message]

These function list comprehension. This is a nice and very "pythonic" 
way of creating list from other collections.

Also, I would suggest to add properties from all getters and setters. 
Python has a property mechanism that enables to avoid getters and 
setter, making the syntax much more readable. Look there for an exa