Penny & Giles faders, and an idea for the MidiBox/LC in general

MIDIbox HUIs
1

Hi there everyone,

I should introduce myself first. My name is Ben, I live in Tasmania, Australia… graphic designer by day, borderline hobbyist/semi-pro recording/live engineer and frustrated guitarist/vocalist/songwriter/producer by night and weekend. I stumbled across the MidiBox about a month ago and have been very excited about making a custom control surface for my Logic Pro setup; unfortunately I’m also very excited by several other DIY projects which I’m already started, so, hehe, one thing at a time ;-).

I just had a simple question: has anyone tried using Penny & Giles motorfaders in the LC project? You just hear about them being a high standard in many commercial control surfaces, was just curious if anyone’s given it a go… or is it still a choice between Philips and ALPS?

Not so much a question, more an idea… have a look at this:

http://www.smartav.net/products.html

and more importantly, this:

http://www.gearwire.com/smart-av-smart-console.html

The idea of having 8-16 faders but 64 or however many level meters with their own access button seems, to me, just pure genius! Okay, there is a question then… could such a thing be implemented into an LC? I’m guessing it would fall outside of what is achieved through the Logic/Mackie Control protocol… perhaps a MIDI to keyboard converter or some kind of small helper app? Just throwing ideas into the ocean… thought it was cool :wink:

Cheers…

2

Hi Ben,

yes, I tried a certain P&G Motorfader type some time ago, and the result wasn’t very promissing - mainly, because the MBHP_MF module and the MIOS based motorfader driver is not suitable for such fast (and power consuming) faders. The complete details can be found here: http://www.ucapps.de/mbhp_mf.html

As for the idea to use 64 level meters: the LC protocol provides only 8 meters and channel strips (Mute/Solo/Select/Rec pair). So, it won’t work, even if I would enhance the firmware by additional events, because the whole handling relies on the host software.

Best Regards, Thorsten.

3

Thanks for the reply Thorsten. I must have read that page several times before, I can’t believe I didn’t notice the Penny & Giles had already been checked :-[. My bad. From what I’ve found out the P&Gs are really expensive too, perhaps that’s no great loss :wink:

Out of the ALPs and Panasonic which are people using more? By the looks of things the Panasonic is the better fader in terms of speed, noise and pricing yet lacks the touch sensor… is that enough to pull people to the ALPs or is a separate switch fine for touch?

On the expanded meter-bridge-select thing… now, please forgive me if I’m being ignorant of something, btw, the idea has been mulling in my head for a few days… on the real Logic/Mackie Control you can add XT expander units - each with 8 full channel strips. Just checking their website now, there doesn’t appear to be a limitation on the number of expanders that can be used… though I’ve read that combined MidiBoxLC projects have a ceiling of 32 channel strips, so I’m presuming you can add 3 XTs.

The ‘full meter bridge’ could be considered to be your LC + x number of XT units, minus all the faders, vpots, etc. bar the “SELECT” switch and level meter for each channel strip. From a MIDIBox perspective, you’d be down to a Core, a DIN4 and however many DOUT4 modules you need to drive the meters per group of 8, yeah?

Obviously to get the advanced bank selecting functions to work - selecting a track/range from any “virtual XT” module and shifting the track mixer view within the actual 8-16 physical faders - would require some pretty serious rewriting of the modules of the LC application. Perhaps some extra custom hardware to help translate too. My current theory is that if the control protocol can be happily fooled (ie. the software thinks that it is just connected to an LC and a bunch of XTs), and there isn’t some limitation in MIOS or the basic MidiBox system which would prevent it from working, then with the right modules and extra code, it could conceivably happen. I’m getting into more serious PIC programming and digital circuit development myself and if it is doable, then would certainly be keen to lead the way, so to speak.

Anyway… that’s how I saw it in my head. I’m really only just starting to learn about the Mackie/Logic Control protocol, MIOS and how MIDIBox does its thing, I’m just working on what seems logical, so certainly if I’m talking out my arse please let me know!

Cheers!

4

Wow, that thing looks pretty sick! Im guessing they are not working on a pure MIDI interface, and have written totally custom driver interfaces for the software choices.

I doubt this is all done on one or two processors as like Midibox. If you look at it from a system perspective, then each module that he pulled out would have its own built in processor. A few power connections to the module and an opto-isolated communications interface on each module would hitch it to the system. Each module having a module type identifier and unique id. Then the slot it is dropped into would attach a ‘location’ ID. All of this gets metraplexed into a main processor, which would then talk to the PC via a custom driver/application.

The passing back and forth of such a huge range of parameters that quickly would require a really fast communication system. Much more so than Midi is capable of?

Sure this is possible in a hobby perspective, if you could throw enough money at it, and most importantly keep it modular.

I dont know a whole lot about the MIDI protocol. I just wonder if it would be worth all the time and effort figuring out a way to squeze all that data down a small pipe, when you could easilly (in comparison) create a new custom protocol?

5

Bad news regarding the Panasonic motorized slide pots…

I talked with one of their reps a while back- they stopped making them.  He didn’t know why- as they were pretty popular.  He got me in contact with the regional distributor whose stock of faders was bought-up buy a couple audio companies immediately after they were discontinued. 

So you MIGHT be able to find somewhere with a back-stock, but good-luck.  ALPs makes the next-cheapest motor-pot at around $25 US (I guess that’d be about $40 AUS or so)…  Which is still about 1/3rd the price of anything from P&G…  But hella expensive for any mortal..

Robin

6

Some words to the idea of virtual XT’s: each Unit requires a dedicated MIDI In/Out pair, this is one drawback, because the Core provides only one MIDI IO. Merging these events with an external MIDI merger (either PC software or hardware based) will lead to new problems, because the MIDI traffic caused by the host when meters are displayed is already so high, that two merged ports would lead to more than 100% of the possible MIDI bandwidth (bottleneck problem).

There are solutions to overcome this, e.g. one or more MBHP_IIC_MIDI modules could be used as MIDI IO expander, or a USB connection could be realised. But the implementation effort is very high - to high for somebody, who is already happy with his MIDIbox LC :wink:

Panasonic/Alps: the Panasonic faders are really great, but today I would still prefer the Alps faders due to the touch sensor - this is a very important feature, not at least because it prevents that values are sent when the fader is not touched - this allows to increase the resolution (because jittering values are not sent when you don’t move the fader), and values are also not send due to case vibrations.

Panasonic Faders with touch sensor: this would be ideal!

Best Regards, Thorsten.

7

Wow, that thing looks pretty sick! Im guessing they are not working on a pure MIDI interface, and have written totally custom driver interfaces for the software choices.

Yeah, it runs on some kind of custom audio engine, I think it is more akin to a digital mixer like the Mackie d8b et. al. The hotswapping stuff is just mad though. Very mil-spec!

TK, just to clarify… the MIDI data bottleneck issue. Is that only when MIDI connections are merged or is it an overall system issue? Thinking back to how the actual LC/MC/XTs are used, don’t they have to give each its own MIDI I/O pair from the host computer? The driver/protocol sees each device separately and does the “control surface integration” from the software itself. If a USB 10xMIDI I/O unit can handle most of those I/Os running at full bandwidth (which is only 31Kbit or something)…?

I think this would require some sort of admendment or extra software with the LC/MC driver to shift focus onto the master (physical) LC though, as the connection between it and the XT meter/buttons would be through the host system only. Perhaps there is a way to interlink them… oh well, perhaps I just better build a standard unit first! :wink:

That’s sad about the Philips faders… wow… 16xAU$40 is.. jeez! Do people do group buys on motorfaders? Is anyone interested in doing one?

8

the MIDI data bottleneck issue. Is that only when MIDI connections are merged or is it an overall system issue?

Both.

From the physical side, MIDI is an asynchronous data stream without handshaking. This means: there is a fixed baudrate, and a receiver cannot hold the transfer if it is not able to handle it immediately.

So, now think about what happens when two MIDI streams should be merged and output over the same interface with the same bandwidth. Once the bandwidth of both input streams is greater than 50% (which is the case for the LC protocol when meter values are permanently updated), the typical bottleneck issue will pop up.

So, this issue can either be bypassed by parsing the streams from a Core which has direct access to multiple MIDI inputs, or by sending the data to the core with an interface which is faster than MIDI (e.g. IIC)

The use of a USB chip has the advantage, that USB itself has a much higher bandwidth, and it’s also possible to provide multiple MIDI In “cables” (virtual devices) for the host application. Problem: MIOS is not compatible to USB PICs, so everything has to be developed from scratch, you can expect ca. 1..2 years effort for this.

The use of multiple MBHP_IIC_MIDI interfaces has the advantage, that this is a known stable hardware, the development effort is much lower (maybe 2..3 months for somebody with programming skills, assumed that he has the hardware already available)

Thinking back to how the actual LC/MC/XTs are used, don’t they have to give each its own MIDI I/O pair from the host computer?

yes…

The driver/protocol sees each device separately and does the “control surface integration” from the software itself. If a USB 10xMIDI I/O unit can handle most of those I/Os running at full bandwidth (which is only 31Kbit or something)…?

Yes… as mentioned above, there are solutions, even with MIOS. I only hope that your question doesn’t mean “if it is possible -> TK: implement this!”. So, it has to be done by somebody with time, motivation and knowledge (I mainly don’t have the >time< to help here, too much other interesting projects are running in parallel)

Best Regards, Thorsten.

9

Yes… as mentioned above, there are solutions, even with MIOS. I only hope that your question doesn’t mean “if it is possible -> TK: implement this!”.

Heheh, I understand. I think you’ve already done enough mate - it was actually quite astonishing looking at this whole project when I first saw it… making homespun tube guitar amps is one thing, but conceptualising, designing and building something as sophisticated as this?! I take my hat off to you.

The only real aim of mentioning the arcbridge thing was to see if there was anything standing in the way of me being able to somehow implement it, sometime in the future. That meant simply not being limited either by the LogicControl protocol system (obviously something I can’t change) or the basic MIDIBox/MIOS architecture (which for all intensive purposes, is working just fine as is). If it came down to creating an alternate version of the LC application, writing host helper apps or designing extra dedicated hardware modules, that’s cool, I can (hopefully) do that, in time. Obviously in the spirit of the MIDIBox project, I’d want to share that with others so they can use it and hopefully improve upon it too.

I guess I was also keen to see what others thought; if enough people said “hey, I like… let’s do it” then perhaps it might (have) become its own little communal project. Hopefully that may happen, but first thing’s first… I better build the base LC!

Cheers all…

10

… there are already other, better implemented control protocolls out there:

EUCON: http://www.euphonix.com/post/products/mc/mc.htm

OASIS: http://www.merging.com/2002/structure/framePyracontrollers.htm

Greets, Roger