Chris Muir

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 

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

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.

-- 
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


mackie-control-again

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 

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 

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 

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.

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.

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.


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 

Lawrence Casserley - lawrence@lcasserley.co.uk

Lawrence Electronic Operations - www.lcasserley.co.uk

Colourscape Music Festivals - www.colourscape.org.uk

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.

Lawrence Casserley - lawrence@lcasserley.co.uk
Lawrence Electronic Operations - www.lcasserley.co.uk
Colourscape Music Festivals - www.colourscape.org.uk


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 

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...

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.

> 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.

Off the top of my head - wouldn't [grab] and a [number box] help you 

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.

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.

Thanks for your replies, I'll give all the methods a go and see which one works best with my patch.

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?

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


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 

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 

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

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

Mackie Control again