i'm trying to build verison 0.17 of the new monome serial on osx 10.4.
my mac is relatively clean... i just got it a couple weeks ago and the
os and xcode are all the latest versions.

straight from the tarchive, doing a build of the broject in xcode gives
me a bunch of errors related to liblo (lo.h not found, etc). ok, so i
find the liblo sources and do the normal "configure" & "make install"
routine. liblo happlily builds a dynamic library and installs it in
/usr/local/lib. (FYI liblo is a lightweight OSC library).

after installing liblo, rebuilding monome serial complains at link time
that liblo.la is not a library. the file exists (in /usr/local/lib), but
it's some sort of text file. xcode is complaining that it's not a
"Mach-O" object file. telling xcode to try to link with the liblo
dynamic library file (liblo.dynlib, i think) does not work; all the
liblo symbols are undefined.

so i'm stuck building this beast. has anyone else sucessfully build
monome serial from the 0.17 download under mac osx? i'm looking for
stories on how to get the liblo.la file to be sucessfully used within
the xcode project.

thanks

bruce oberg

ok, i figured it out. the configure script for liblo is pretty standard, 
and without any tickling it decides to build plain osx ppc binaries. to 
get "universal" binaries (both ppc and intel), you need to set up a few 
environment variables, as per this web page:

http://developer.apple.com/technotes/tn2005/tn2137.html

once i got a universal library built, i could link liblo.dylib with the 
xcode project and run monome serial.

good work! though we've included the binary .app also.

are you planning any modifications?

yes, i am planning on making some changes. while i'm suuuper happy that 
monomeserial is now mostly the same on both platforms, i'd like to see 
some of the user interface cleaned up.

furthermore, i think there's a huge opportunity to have monome emulators 
running while still using monomeserial as the hub for connecting them to 
osx or midi. having easy to use emulators is a great way to continue 
working if/when you don't have a physical monome around.

i'm writing some games for the monome in python and c++. i'd like my 
stuff to be cross platform, and having a solid monomeserial is the key 
to that for me.

is there a mailing list or forum for people working on this driver level 
stuff? and is the code for monomeserial under source control somewhere? 
as i rummage around, it sure would be nice to get the latest "official" 
code and/or submit fixes.

theres no list or anything, but you can feel free to contact me, 
kid_sputnik at yahoo (im doing the Windows version, im somewhat familiar 
with the OSX code too).

os x version was created completely by one person so we never bothered 
with version control. the most recent is posted on the wiki.

i'll consider implementing version control is there's sufficient demand.

thanks for posting the link to the TN2137, entros.. that saved me some 
sleuthing!

i m doing :
$ env CFLAGS="-arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc"
$ ./configure --disable-dependency-tracking
$ make
$ sudo make install

and i still have the same error (bad magic number : not a Mach-0 file),
what i m doing wrong ?
Cheers :)

unfortunately i've never delved into compiling monomeserial. if someone 
gets it compiled properly, a quick walkthrough would be great.

anome... a couple things to check:

- ensure that you've 'clean'ed out any old install before running make 
with the new env settings. make doesn't consider enviroment changes in 
its dependenciy checking. it only considers file existence and 
timestamps. so if you build it the wrong way once, you have to do a 
'make clean' before building again with different environment variables. 
otherwise make will not build anything, thinking everything is up to 
date.

- it appears your 'env' command is on a seperate line from your 
'./configure' line. this is not how TN2137 describes how to do things. 
look at their page, the 'env' line continues to the './conficure' 
command. i'm not completely sure, but i believe this is important. unix 
can be tricky about 'exporting' environment variables and calling env on 
a seperate line may not get the variables exported to the './configure' 
command. i actually put the variables in my .bashrc file (ensuring they 
were also exported form there) and relogged in.

- TN2137 also says that CFLAGS should include "-O -g -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk", which you're not doing.

- finally, i had to manually adjust the xcode project to link with the 
liblo.dynlib (or somthing like that) instead of liblo.la.

cheers ! i did it :)
now i m ready to dig the beast


a couple of things in response to entros :

1 - yeah, "make clean" is important when compiling again
2 - I think the same, the whole line should be typed instead two 
separate lines but it works for me
3 - including such args is only needed if the machine which compiling is 
a powerpc (see in the apple's link)
4 - as I m new to mac, a couple of tips : Option+O to display the 
project window, open "Frameworks" on the side menu and delete 
"liblo.la", then right-click (or whatever) on "Frameworks" and choose 
"Add->New Frameworks" to add /usr/local/lib/liblo.dylib (usually here). 
Tips: if you dont see this /usr in finder, type Option+Shift+G to go in 
this folder ;)

hope it d help someone ...

have you gotten monomeserial to compile and link liblo into the app? i 
remember this being a problem earlier, where we got it compiled, but 
then it required the user to install liblo on their system. (this is 
bad, of course).

some day i'll learn this part... it's pretty much the only thing i've 
tried to keep my hands off of.

i have only made it work with dynamic linking. that's good enough for my 
twiddling, but as you say, bad for distribution.

Hey entros:

Did you check serial-pyio ? It is in python, can be used to easlily make 
games in python for the monome and has a virtual monome. Next phase is 
multi app support. Look there : http://forum.monome.org/topic/1157#new 
and there: http://sourceforge.net/projects/serial-pyio/

What you plan to implement seems to be almost implemented in 
serial-pyio. Maybe you could contribute ?

Julien

thanks julien, i'll look into that.

do you guys feel like serial-pyio is a legitimate/viable replacement for 
monomeserial over time?

my main concern was that people would have to install python, though 
maybe i'm too sensitive about that?

i'd really like to find time to dig into python, waiting to find a free 
evening

i would not predict that any python based system will become a legit 
replacement for monomeserial. i think of monomeserial as a device driver 
and device drivers have to be FAST. already in my own python apps, i've 
seen noticable slowdowns in some cases. the monome needs to be wicked 
responsive in order to work at all, and basing core things on python is 
proably a mistake in that regard.

in a way, the monome effort is facing the same sorts of issues as any 
programming system that relies on performance. you need the low level 
stuff to be written close to the metal for speed, but you also need 
higher level abstractions for anyone to do cool apps.

i'm already leery of monome serial being written c# under windows. i 
mean, think about the levels of abstraction between, say, a max/msp app 
and the actual monome hardware right now:

some cool app
max/msp
osc
monomeserial
c#/CLR runtime (interpreted bytecode, not x86 code)
OS serial io driver
FTDI driver (faking serial IO over USB)
OS USB driver
actual monome

with some many points of failure, it's not surprising that many folks 
can't get simple demo apps running. turning monomeserial into a python 
app would only make this more fragile.

i dream of a monome driver that is written in native code (probably c++ 
both on xp and  macox) and speaks directly over USB (perhaps using 
FTDI's libraries), while also speaking MIDI and osc. the hope is to 
collapse the CLR/serial/FTDI layers out of the equation. this is what 
i'm going to try to do this fall.

yah, im slowly working on a C++ windows solution as well, but i need it 
to work for new devices first with the current code.

that said, the reason i want to do it is because of simplicity, in that 
there is no need to download any other libraries (especially from MS, 
which people are leery of).  any major issues with monome serial XP are 
my own programming goofs, really.  .net's bytecode (actually more of an 
assembler language that you can program in if you want, called msil) 
compiles any classes and objects to native the first time they are 
called, so the only problem with speed is at startup (its JIT compiled, 
not interpreted at all).  and even the JITer is probably trivial, its a 
relatively small app.  also, alot of the low-level stuff is done via 
Native Win32 interop, which is also fast (esp since im dealing with 
byte[]s only).  there is actually an "unsafe" option when dealing with 
bytes and low-level code that lets you use pointers and put objects on 
the stack, without the garbage collector, but everytime i tried it i 
didnt see any sort of benifit for it to be worth it.

speaking of garbage collection, that is another non-issue really, ive 
done tests actually with the adcs running and me bashing away at keys, 
and it still doesnt occur from between a second or 2 to several seconds, 
so really again its not that bad.

the serial protocol is just too simple, literlally passing 2-byte 
packets on the 40h.  really, the part that is more trouble IMO is OSC, 
which is alot heavier, but my C# OSC code is very lightweight and i 
havent had any issues with speed so far.  of course, for something like 
a full-fledged audio app like REaktor or even an oldie like Pro53 i 
wouldnt bother with .net, but for a simple serial driver it has been ok 
so far.

>  turning monomeserial into a python app would only make this more fragile 
Can you explain this ? I mean in your stack you just have to replace the 
c#/CLR layer with the python interpreter, which does make it more 
fragile or stronger. I am only using the monome under linux for instant, 
and so I have no knowledge of the windows/macOS applications that raise 
problems. But wouldn't it possible that some problems come from the 
application themselves? I mean, launching several midi apps at the same 
time was (some years ago) a problem. Sharing midi ports and so on...

Considering the speed. Python is not fast compared to C++. That's true. 
But for may library calls, such as network calls, python has little 
overhead, since it is just a thin layer (binding) calling directly the C 
library. I see it as a prototyping language. This is the goal:

- make serial-pyio being able to share the monome with multiple 
applications.
- make serial-pyio being able to handle multiple units
- make sure the design is maintanable, extensible and flexible.
- make all of this quickly: I like coding but also want to do music !

For these these four points python is very strong, at the cost of a 
smaller speed.

Once this is done:
- check where time is lost and implement these small parts in C, if 
needed.

Then we'll have best of both worlds: high level programming 
possibilities with good performances.

From my point of view serial-pyio is not a device driver. It is a 
router: it receives several flows of events and distribute them to 
destinations. You can of course change the distribution at run time. To 
make a parallel I see monome serial or serialpy-io as equivalents of 
Jack and not as equivalents of an alsa driver. Jack is very inspiring 
from that perspective. And yes I know jack is not programmed in python 
;)

Squashing layers has always been a concern. Look at X11. Squashing 
layers and keeping flexibility is a pain ... I would not go there, 
possible benefits are too uncertain considering the huge time investment 
it requires.

Julien

I managed to get the static linking work finally by:

1) Removing liblo.la (?) from the XCode project

2) ./configure --enable-static --disable-dependency-tracking 
CFLAGS="-arch i386 -arch ppc"

make; sudo make install

3) adding liblo.a to the project


Best,
Steve