Dunewar

Now this is something I would be very interested in! The site mentioned only has the communication in one direction (from HUI to computer), any chance of getting the communications in the other direction as well? (what is the computer saying to the machine to drive the leds and the LCD) I'd be more then interested in working on the software for this, I was going to build a first midibox based on the Motormix, but this is much more interesting (it has a master fader).

I know that this it can be done by adjusting the messages it sends out to conform to the JLcooper CS-10 control surface (that's what digidesign themselves suggest), but not everything is mappable that way, it is pretty limited. I could also use the motormix protocol that TK has elegantly coded allready. But I was being curious if I can take it one step further, and implement my own control surface into pro-tools without limitations and without conforming to someone elses protocol (like you can in Cubase with the generic controller).

I've been looking into using the Jlcooper CS10 protocol, or the motormix protocol, to use a midibox with pro-tools. I notice that you get a DLL with the jlcooper protocol in there to allow pro-tools to use it (as with the other protocols). Now my question is this : what is in those dll's? Is it possible to in some way re-engineer these? Or to make your own dll's that pro-tools can read? Or am I dreaming out loud?

Thanx guys, that's exactly what i'm doing, going through the code. The motormix emulation by TK is incredibly well documented and nicely coded, so it's fascinating to trawl through that code. I'm learning a lot of C in the progress (especially bit-shifting...new to me). Since this is my first project of this kind, i'll start small and add new features conforming to the motormix emulation code one by one, customising the whole thing in the process. thanx

Hey, I'm aware of the fact that there is no shift function in midi, it's just another CC that tells the software how to interpret the other messages. I'm glad to hear that no problem comes from inserting multiple functions per knob/button. I will try that out. I want to make a controller that has one knob per function that I want. So I might leave out functions that the emulated machine has but that I don't need, and on the other hand implement two buttons where the emulated machine has one button + shift button. So it's really that simple, send the CC for shift-on, the CC for the button in question, and the CC for shift-off.... Thnx man

Sorry for the obviously stupid question, but it's not very clear to me. What makes a software program think that a certain device is attached to it? How is a certain emulation protocol implemented? I've been looking at Thorstens code for the motormix emulation (impressive work), but I want to adapt it. I don't need all functions, and I want to make changes to the physical layout (spreading multifunction knobs/encoders out over multiple knobs). I have all the midi messages that the machine and the host send out to each other, is it just a question of sending the right messages, or does it have to be followed to the letter? To give an example : If I were to implement just one fader and one fader only, and it sends out the correct data for an Logic Control fader 1, does it matter to the HOST that the rest isn't implemented in the software? I can imagine that a PING REQUEST-PING RETURN is necessary to make it function, but can I implement feature per feature in the software or do I have to have the full protocol in there from the start? Not that I don't want to use TK's software, but I want to see how far I can take a control surface and still be conform a known protocol, because bloody pro-tools doesn't understand any better...

I don't know if my topic makes any sense, but what i'm trying to figure out is this : When emulating a known device (because pro-tools doesn't accept generic controllers), is it possible to split out functions that are originally done by one button/knob ? For example, one pot does two functions depending on the shift button, is it possible to program two pots to have that seperate function so I don't have to use a shift function? My idea is the following : let's say that a pot controls SEND when shift is pressed, and PAN when shift is not pressed, and I want to spread that out over two pots. Then what would happen in the software when I move the SEND pot is this : - send a SHIFT-on message to the host - send the CC numbers and values - send a SHIFT-off message to the host The PAN-pot would then have the same CC number, but without the additional SHIFT message. Is this correct? Could this work, or will this generate too much midi traffic? Sorry if this seems very newby, but i'm trying to figure it all out before embarking on my first project, and i'm completely new at this. Any feedback would be greatly appreciated. And for the record : TK, your source code for the C examples is unbelievably clear and well-written, those are exemplary pieces of C-coding.

hmm, i'm starting to think that a MM emulation-based Midibox LC is too dificult for a first midibox project. Maybe I should stick to a Midibox 64 first (and develop a JLcooper CS-10 emulation for it), and make shure it can be upgraded to a MM later on...

no-one interested? Come-on people... :(

I've looked into the programming, and rearranged the table somewhat (TK had some empty spaces in there to conform to his LC, which I won't have), and I came to this list of modules (without buttons/encoders etc...) : 1x CORE 1x MF (+8 motorised faders) 3xDIN 3xDOUT 1x 2x40LCD Does this somehow look right? This is based on the file mm_dio_table.c. On some places, it says "(in my setup encoders are connected here)". Does this mean encoders not used for the MM emulation, or encoders necessary for the emulation? Also, a couple of other questions concerning the MM emulation : -is it possible to include a couple of encoders that spit out general MIDI CC's, to control a softsynth or plugin from the same control surface? -in the file mios_tables.inc, there is mention of a jog-wheel encoder, but the motormix doesn't have a jog wheel, does this refer to the encoder that selects the function of the other encoders? This is my first major DIY project, so I want to be prepared before I order anything, so sorry for any obvious questions that I may have asked..

Nice work! What are you running this on, Midibox LC or 64 or did you write something yourself? About the leds : are they all seperate leds? is there no way to get a led-ring in one piece?

Hey Roger, That's actually a good point about the motorised faders and automation, I didn't think of that. I suppose it could be worked around by having the faders play 'catch', but then again it's still a hassle. So I suppose motorised faders are on the table for my design. I did some more research on the motormix emulation, and on the cm labs website, they have a developers guide that has all the codes sent out and returned to the machine, so when something doesn't work, it should be easy to troubleshoot. So motormix emulation it is, and motorised faders it is. Has anybody done this emulation before?

I've done some research, and it's not entirely clear wether the motormix emulation works in ProTools. Some say it does, others say it doesn't.... I suppose only the motormix and LC emulations work with motorised faders? Does anybody know something about this? I suppose a MB64 is easiest to make. I then have to configure it as a JLCooper CS10 emulation. I would probably have to use two mb64's linked together But of course, you people have made me curious about moving faders. I have never used them so I don't know how important to my workflow they are. Would you be able to live without it? I'm now looking at the motormix manual to see how handy an emulation of that might be. It would also be nice to include a set of generic encoders to control plugins from, on the same surface. I've looked at the source code, and reprogramming it to my needs doesn't look so difficult. The source code is incredibly tidy and well-kept, an example for all programmers out there! How much harder is a motorised fader project compared to a regular MB64? I'm mainly worried about the power requirements, i'm not used to dealing with PSU projects. Sorry for all the questions, i'm trying to understand how everything works, and that is kinda addictive. :P

Thank you screaming_rabbit for keeping the discussion out of this place. I'm nowhere in a comparable situation, i'm an amateur working at home on my own ideas. The only thing that I record is my own band (and i'm pretty happy with the results i'm getting). I have no experience in other DAW's except for cubase SX2, and I didn't like it. But that's personal preference. Thanx for your insight on the design though. Now for my idea : I first want to plan the entire design before I purchase or make anything. I could be persuaded to get motorised faders though, but isn't that very expensive when I want 16 faders? What exactly are the benefits of motorized faders over non-motorized. Obviously, when you open a file your faders are where they should be, at all times. Why isn't automation doable with non-motorised faders? When writing automation you are overruling the motorised part anyway, so only in playback does the motorised aspect work. Regarding the motormix emulation : i'll look into all documentation I can find about the motormix. Is it expandable beyond 8 faders? Does anybody here have any experience with it? Maybe I should cut back on faders, but I hate flipping through channels... I realise that buying a second-hand motormix or HUI won't cost me that much more (if even), but I like having a custom controller, and I like the challenge of doing it myself. Indulge me 8)

Hey Rowan, Actually I'm looking forward to building the thing myself, so I don't really want to get a tascam or Behringer. As far as the HUI goes : is there any way a good programmer could program this? I'm not familiar with programming a chip, but i'm pretty good at programming and learning programming languages, plus I like a challenge. I just went through the source code for the MB LC, and it doesn't look too complicated. Or am I dreaming? Is there any info on the mackie HUI protocol? As for the JLcooper emulation, is it possible to have more then 8 faders? The midi implementation chart only shows 8 (and room for 8 in the CC's), but apparently an expander is available so it should work with more then 8 channels?