Forced Prefixes

  • What's peoples opinions of the patches that auto-update Monomeserial with the proper prefix?

    See here's my dilemma, I use multiple monomes and sometimes mutliple patches on a single monome. It takes a while to get everything setup. When say I have MLR on one monome then I open boiing and it updates both boxes with the same prefix. I have to go in an manually flip it back. I'm sure most people aren't in this situation. But was wondering if anyone has a good solution for my problem? What part of the patch do I adjust to turn off the auto-prefix?

    I think overall its a good idea to have the auto-prefix...But I'm thinking ahead to a live situation where I have a couple things running I don't want to waste time switching over prefixes for each box. Is there a way to send the prefix to a particular box attached to Monomeserial?

  • hey c1t1zen, i totally forget how much max knowledge you have, so forgive me if i get really basic here.

    any patch that updates the prefix automatically will have a [[loadbang]] object (which sends a Bang! when the patch is loaded) connected to the [/sys/prefix ...whatever] message. disconnecting that will prevent it from updating automatically.

    careful to only disconnect the loadbang from the message though, and not the message from anything else, otherwise the message button won't work

    in the case of boiingg, the loadbang is nestled deep in the functionality subpatch.

    to set individual prefixes, you use send, for example, [/sys/prefix 0 /mlr] and [/sys/prefix 1 /osc]

    so now device 0 controls mlr and device 1 controls boiingg.

    the problem here is that i think device numbering depends on which device you plug in first.

  • Yeah, best to say I have no Max knowledge and more people can understand it.
    I've only made it halfway through the tutorials so far.

    OK that makes more sense to me, I'll try my hand at modifying the patches I use most and try making a simple patch with the send commands you mentioned. I'd love to get a switcher setup to my midi controller to load prefixes on the fly. I'm getting so close to what I need for a good live setup. Thanks Kevin.

  • you raise a very valid point.

    the indexing system is very flawed in monomeserial. how in the world do we know which unit is #1 and #2 etc?

    daniel suggested previously that we reference by serial numbers. not a bad idea.

    unfortunately monomeserial is hard to maintain and upgrade. not enough people have the skill set or dedication.

    again, i'm voting for a redesign in python, but i know that's not the answer for everyone.

  • Tehn, I'm going to test this out this weekend. At least on PC side each monome is assigned a different Com port. Could that be a solution?

  • tehn -

    I know I keep harping on about this, but I think an svn server (or some sort of publically accessible code dump) for monome serial would make it much more attractive for people to tweak.

    There is no buildable source bundle for monome serial available, that in itself is a pretty big hurdle to encouraging development...

    I'm happy to help out with organising this sort of thing if that's what's needed.

    -e

    ps I'm totally cool with a Python version either, but I've found in the past that switching languages is rarely the panacea it appears to be

  • if someone wants to start a sourceforge project or similar, that's fine by me.

    really, it's going to take initiative on someone else's part to push monomeserial forward. both steve and daniel completed what i requested (and compensated them for), and i don't have short-term intentions to fund further development until we properly design a next phase.

    part of my desire to switch to python is to work within an environment that i'm capable of using, and something that all platforms (os x, xp, and linux) could take advantage of. i agree that switching languages doesn't promise all, it simply brings about different problems (problems i'm more capable of handling on my own, in addition to potentially being more accessible to others).

  • tehn,

    daniel and I have talked briefly about the possibility of using the libmonome project I started as a cross-platform monome serial interface library. currently it's functional on Linux and, I presume, OS X because it's just using the standard POSIX way of accessing serial devices, and I'm working on decoupling the serial code from the protocol code so that support for Windows COM ports can be added as well. there's already a monomeserial implementation included with it, though it's guiless at the moment and doesn't support the /sys prefix just yet.

    it's started off as a project chiefly so I can use my 256 on linux, but I've been quietly scheming about ways to make it a more capable drop-in for monomeserial. currently I'm hosting a mercurial repository on my own server, but I'm willing to perhaps register a sourceforge or google code project if there's interest.

  • A python monomeserial sounds like an interesting project. I've been using the OSC library and it seems like it would take care of most of the ugly stuff in listening and sending.

    But i do wish that monomeserial worked as a background daemon, or service in windows. I'd rather just have it available, and not think about it. Any opinions? A daemon could be written in mostly cross-platform C++, separate from any control-panel-type GUI. I don't know if python would be as amenable to being a service without being fussy.

    What kind of things do you see addressing in a next phase?