Mackie Control again


    Feb 12 2006 | 6:15 am
    I've searched the archives on this and did not find anyone actively
    working on Max support for the Mackie Control. I'm pretty far along
    on providing basic support, but the process has really made me
    respect the seamless and deep support that Logic provides.
    At any rate, if there are a couple of Mackie Control using Max-heads
    that would like to beat on this and give me feedback, please get in
    touch.
    -C
    --
    Chris Muir | "There are many futures and only one status quo.
    cbm@well.com | This is why conservatives mostly agree,
    http://www.xfade.com | and radicals always argue." - Brian Eno

    • Feb 16 2006 | 11:58 am
      I got as far as writing the mxj code for speaking mackie-controllish (or
      at least most of it). What I didn't do before I wandered off to
      something else was:
      - state management
      - any sort of UI.
      This was because I couldn't decide what level of generality would be
      useful for maxxers: the MC manages none of its state (not even fader
      position), which means that the behaviours are more or less arbitary.
      Obviously, whilst it would be useful to present a model that functions
      as a mixer interface, the spirit of max suggests that there should be an
      easy way for users to set up different models for it that can be more
      specifically tailored to their own work.
      That said, if you're really interested in getting at least some level of
      support a la logic together (perhaps something that's similar to the
      motormix objects in concept), I'd be delighted to share what I've done
      so far.
      --
      Owen
    • Feb 16 2006 | 9:17 pm
      Hello there
      I'm afraid i'm not that much help cos I've just started writing a patch for the Behringer BCF2000 control surface (similar to mackie), and I'm running into problems -
      can you tell me how to prevent midi feedback loops when sending parameters to and from the controller? This would be much appreciated.
    • Feb 17 2006 | 9:23 am
      The main thing is to ensure that the incoming midi data is not being
      resent, but you shouldn't need to do that. If you look at the patch I
      posted I use a coll to store the banks of data, each one in its own
      line. I only need to send data to the BCF2000 when I switch banks, to
      return the faders to where they were when the new bank was last being
      changed. I do this by sending out one line of the coll. New data is
      also sent into the same line of the coll, but writing to coll does not
      trigger output, so there is no loop. If you are using individual
      objects to display the data you can produce a similar effect by putting
      a 'prepend set' object before each one, which updates the object, but
      doesn't trigger output. I just think the coll + jit.cellblock approach
      makes for a much simpler patch, but you might have good reasons for
      doing it the other way.
      Best
      L
      Lawrence Casserley - lawrence@lcasserley.co.uk
      Lawrence Electronic Operations - www.lcasserley.co.uk
      Colourscape Music Festivals - www.colourscape.org.uk
    • Feb 17 2006 | 1:23 pm
      You might want to adjust 'dead-time' parameter on your bcr/bcf. I won't have
      access to bcr until Monday, so can't tell you exactly what you need to do,
      but I think it was necessary to enter the global setup menu(EDIT and STORE),
      and adjust the value with encoder 7. I think this info was somewhere in the
      manual...
      hth,
      nesa
    • Feb 17 2006 | 3:17 pm
      On Feb 16, 2006, at 4:17 PM, Toby Scott wrote:
      > can you tell me how to prevent midi feedback loops when sending
      > parameters to and from the controller? This would be much appreciated.
      in my patches i've just used [gate] on the input to prevent anything
      from coming in when i'm sending out. on the output i do somthing like
      [t 1 l 0] witht eh "0" and "1" connecting to the input gate's control
      inlet and the "l" being my outputs to the controller.
      best,
      jlm
    • Feb 17 2006 | 4:07 pm
      Off the top of my head - wouldn't [grab] and a [number box] help you
      do this?
      I haven't used it for a wile, but I seem to remember it as the best
      way of isolating an input from being sent straight back out again.
      David
    • Feb 18 2006 | 4:30 pm
      Thanks for your replies, I'll give all the methods a go and see which one works best with my patch.
      Cheers!
    • May 12 2006 | 8:23 pm
      Hello!
      I just bought a BCF2000, sure of being able to use in Max, and in fact no way.. I should use to control 3D/video parameters, and need the surface to react bidirectionally..
      i read archives about the bcf2000 and noticed Toby are implementing some objects to control it? Did you get to an end? Do you intend to share it?
      Thanks for your help..
      livio
    • May 13 2006 | 7:03 pm
      hello,
      here's something made for bcr2000, but it should work with bcf too.
      this one sets controller properties, so you can for example set encoder
      ranges from max:
      and here is nrpn input abstraction, you can use it to send 14bit values,
      wich might be necessary for what you're doing. paste it and save it as
      nrpin.pat:
      and something that will be help file(nrpin.help):
      this is unfinished stuff, so it probably doesn't work quite good. for bcf
      related object, you should check excellent jasch collection: www.jasch.ch
      best,
      nesa