Linux - Am I doing this right?

  • Hi guys!

    I've been trying to take a serious dive back into my monome lately after a pretty long time of not really working with it much. I'm working on debian. I have been making all of my programs from scratch, as I would prefer to use PD and my own C or Python programs over Max (not that I can afford it or anything).

    I have a program I call the bridge that holds the port to receive all osc from the monome. This program serves as my central hub in that it redirects presses to other osc ports for other programs to receive and act on. Additionally it also provides a way to change between monome programs by giving an interface on the monome. When I press on a button on the monome that corresponds the program that I want to switch to, the bridge starts to redirect all presses through itself (in an infinite loop) to the program I have chosen. The prefix in monome serial for my monome is also switched so that it will respond to the led info sent from the program that I am switching to. Is this a customary or functional way to do things. I really want to be able to move through and use several programs with my monome easily

    The main reason I ask is because I have seen with the Max apps that each app has a prefix and changing apps is simply done by changing prefix. On linux, I think that each port can only be held by one program. So how can I change between monome apps on linux in this mannar? Would it be practical to just switch the port setting in serialosc around to accomplish this?

  • most use "pages," a wonderful app that works on linux, to use multiple apps simultaneously.

    cool that youre doing it from scratch though. im not expert but personally i would change serial settings as little as possible, and have traffic all controlled by the bridge app.

    e.g. if (prefixReceived == activePrefix){ send the /led/set message to serialosc;}

    less moving parts that way.

    are you using monomeserial (an old old protocol) or serialosc?

  • I am using serialosc. Thanks for the advice.

    Why is it that there are fewer moving parts when the prefix setting of serialosc is changed less (and all the trafficking is handled in my bridge or in pages)? If the led info is sent directly to serialosc and filtered via the prefix, then doesn't that save that middle step back through my routing program and reduce moving parts?

    The main reason I bring all this up is basically because I am concerned that the bridge may decrease responsiveness of my monome. Routing osc signals through my program creates the need for two osc signals (one from serialosc and then another from the bridge to my desired program) for each button press. The bridge works by looping infinitely, so the wait time between loops adds at least a little extra time between messages. I think this must be a sacrifice that pages would have to make too.

  • You should be able to use port routing to direct your osc traffic. However, you're right, I don't think you can have multiple listeners on the same port. The osc protocol is made up of udp packets, so you'd probably have to hack liblo or whatever osc library you're intending to use in order to do something like this:
    http://stackoverflow.com/questions/4364434/let-two-udp-servers-listen-on-the-same-port

    It sounds like you are using C?
    I think you have 2 options:

    1. Reduce wait time between your checks
    2. Use linux's epoll interface for more event-driven polling

    If you are working in C though.. your latency concerns should be pretty small unless you're performing some computationally intense processing in-between. Have you tried to put your polling in a separate thread?

  • murray, thanks very much for your input!

    Actually, my bridge application is written in python. Im using a wrapper of liblo for python. http://das.nasophon.de/pyliblo/API.html

    Even using python, however, I think I should agree with you that latency should not really be a problem under this method. I have been using a 10 milli second wait time in my loop so far and have not been able to notice any latency at all. Further more, I just found that the recv function (the function called to check for a recieved message and deal with it with that appropriate callback function) in liblo is pretty nifty. It allows for making the program block explicitly until it recieves a message.

    Over all, I was asking because I was just wondering if this method was the 'idomatic' or standard way of doing this (is there a better or preffered method?) and also, because I am wondering why everyone seems to be afraid of changing the settings of serialosc, especially the port that it listens on, on the fly.

  • @harlequin, i see what you mean, yeah. i'm inclined to avoid changing serialosc settings just to have a better idea of what's going wrong when something messes up. not having to wonder if serialosc got the message and/or did the right thing.

    really though you+murray are more experienced in this than me - i'm just exercisin' the ol' noggin.