Jump to content

LED VU Meters, Encoders and SSD1306 Displays


ibanman555
 Share

Recommended Posts

Hi Everyone,

I initially intended to build my own complete 32 channel DAW controller for Pro Tools utilizing the NG core. However, I found a much higher quality fader surface for a steal of a price I am integrating now.

These lack encoders, displays, meters and a 'timecode' read-out... all of which I am hoping to build and add to the exsisting surface myself.

Im hoping someone could shed some knowledge on what parts I would need in addition to the NG core to complete this project.

For 32 channels, what is the max # of leds I could program for VU meters, per channel?

32 encoders, and 32 displays (preferably SSD1306)?

Thanks so much for any advice!!

Link to comment
Share on other sites

 However, I found a much higher quality fader surface for a steal of a price I am integrating now.

These lack encoders, displays, meters and a 'timecode' read-out... all of which I am hoping to build and add to the exsisting surface myself.

Which "fader surface" are you considering as a starting point for your project?

Link to comment
Share on other sites

For 32 channels, what is the max # of leds I could program for VU meters, per channel?

 

Thats a good Question. I assume that you cant combine 2 Matrixes together so there is a max. of 16 LEDs per Matrix. For 32K you will need 2 Matrixes.

http://www.ucapps.de/mbhp/mbhp_doutx4_ledrings.pdf

 

for 32 Encoder:

http://www.ucapps.de/mbhp/mbhp_dinx4_16enc.pdf

 

for 32 OLED:

http://www.ucapps.de/midibox_ng_manual_lcd.html

scroll to the bottom. There you can find nice Schematics, Fotos and the Details.

Link to comment
Share on other sites

well im not so shure in this. I think it shold be possible for MBHP_NG to assign 16 LEDs. 

you will have to try.

 

Im asking my self how to get to the Data of Metering. I thought that the Protocol supported through ProTools does not provide Metering..? Are you using Midi ore RS232 (somehow???) in ProTools?

Link to comment
Share on other sites

I am not sure of how to get external metering via pro tools either. This is where I hope for assistance.With the ES/8-100 I am converting RS232 to MIDI using Hairless Serial>Midi program. From there, I am using MidiOx to change the values to something Pro Tools recognizes. I have moving faders, mute solo and select functioning properly within Pro Tools with the existing surfaces.

Control 24, C24 and Pro Control interfaces all have meters per channel... so how can we make our own to work the same way?!

Edited by ibanman555
Link to comment
Share on other sites

Hi,

 

you would need some documentation for these surfaces which contain the sysex implementaion (assuming the meters are transported via sysex). Once you have this, you can set up a receiver event inside MB_NG that can get the sysex events and "translate" them into led or lcd events. I know, this is possible for the Mackie Protocol.

 

I don´t know if there´s a public "implementation chart" available for control 24 though, you might need to reverse engineer this, if you can get your hand on one of those surfaces.

 

Here you can find a conversation on the Reaper forum regarding this topic. I don´t know, how far they have come, but it might be worth a look.

 

my regards

Link to comment
Share on other sites

Well, those "controll" Surfaces are actualy also Soundcards. So they have a direct Audio-Stream and those meters can be activated by Audio directly in the controller.

 

Even when the metering data is distributed on LAN. the Protocol described in the Link of JohnE.Finster is Layer 2 so OSC isn't (please correct if false...) a option as well. You wold need to write your own driver on top of a midibox core...

On the last page of that topic you can read that several guys tried to get the EuCon Protocol to make their own thing but didn't even get an answer. Avid owns the protocol and keeps it secret it seams...

but it wold be a nice thing to have...  :phone:

Link to comment
Share on other sites

I won't quit...

As far as I understand... the Pro Control is just that. A controller. There aren't any actual I/O on that surface. However there is still metering. Another surface, Icon Pro... can interface with Pro Tools and also has metering. I wonder how they managed to get it working.

Link to comment
Share on other sites

A possible compromise in this case could be combining different protocols.

 

I don´t have Protools, but I believe, it also supports Mackie Protocol. It might be possible to attach a (MB_NG-) meter bridge to your faders which is driven with Mackie Protocol. There might be issues to work out if you want to sync both "elements" (e.g. fader bank switching,...). But as said, I don´t know Protools and its possibilities on that area. I guess you will have to set up a lot triggers and translations e.g. with midiox and others, but so far as I understood, you are already doing this to get your faders going.

 

How can your Fader boxes be connected to your daw?

What kind of protocol are you using now? Are there other (midi based) protocols inside Protools you could exploit?

 

Novski is certainly right about Avid, they´re a pretty uncommunicative bunch when it comes to their products. The only possibility one has to get behind the curtains is to reverse engineer their gear. But even then I believe there are technologies involved, which can´t be emulated with a Midibox Controller.

 

my regards

Edited by John E. Finster
Link to comment
Share on other sites

I believe so, yes, using the Mackie Protocol from Klinke. But I´m not completely there yet.

 

I was able to display the meters on my ssd1306 displays and generally they work, but there are a few things I have to work out before I could say, they´re completely usable.

 

The problem seems to lie inside the Mackie Plugin from Klinke. Normally (with the MCU) the meters are activated by a sysex string followed by a stream of Note and Aftertouch events to transport the meter values. I was able to reproduce the stream, so my meters are "twitching", but I´m still missing the proper sysex string. Same goes for the MTC display, btw.

 

As I said, I believe it´s doable, but there has to go a bit more work into it.

Link to comment
Share on other sites

Ahh, I see light.... :w00t: .

(sorry, I had to put my grammy into a hospital last night..........again.......... so I´m a bit exhausted. Ok, back to topic!)

I don´t know about the command8, but the others, HUI and Motormix, are documented.

With HUI you might be able to set up....:

- vu-meters -> transported by a key aftertouch event which could be recognized by a MB_NG and translated into a led or lcd event.
- encoders, switches, led-rings -> they´re all continous controller events which can be assigned by MB_NG
- 2x40 lcd display -> for displaying fx parameters (like HUI), sent within a sysex stream which could also be recognized by MB_NG and displayed on a lcd.


With Motormix you might be able to set up....:

- 2x40 lcd display -> track names, also sent within a sysex stream.
- encoders, switches, led-rings -> like HUI


You could combine both protocols into one "midibox bar" to attach to your fader boxes. HUI could give you metering and Motormix could give you LCDs with track names,...


I recommend you monitor the midi output of all 3 midi protocols (from command8, too) to see, what and how controller information is transported (this can differ from daw to daw). You already know Midiox, which is an excellent tool for that. Just connect the midi out of protools midi protocols to midiox (via LoopBe or other virtual midi cable) and record the output. If everything is alright you should able to see note/controller/aftertouch/sysex commands from protools, which we can interpret and maybe emulate.


A word of caution to this tale...(my kid loves that disney Hercules movie...)

1. Everything I wrote here is considered hypothetical. I got similar stuff to work with my boxes, but of course I can not guarantee that any of this will work in your case. Especially, since I don´t know Protools and its potentials.
2. Since you´re focused on meters I´d like to add another comment. Midi-driven meters are never that accurate as audio-driven meters or those you see on the screen of your laptop/pc/mac...whatever. They can be (rough) indicators of what is going on, the whole meter length is roughly divided into 11-13 sections and they have a noticeable latency. If you´re looking for professional and precise meters, a midicontroller is might not be the solution.


Then again, I am really tired right now, so if any of what I just wrote doesn´t make any sense, please bear with me :ahappy: .



my regards

 

 

P.S.: If you can give me some time, I could test the metering feature of the HUI protocol within Reaper (IF it supports metering) and report back.

Edited by John E. Finster
Link to comment
Share on other sites

Am i wrong thinking MF_NG has to operate in Motormix emulation anyway...?

 

If you want to use a mackie/logic emulation, you´re right. For other applications you could use other modes.

 

I believe it has something to do with the resolution of the faders. The Motormix mode provides 14bit fader resolution.

 

my regards 

Edited by John E. Finster
Link to comment
Share on other sites

Yeah, it´s kinda interesting. I had to look twice a the midi input monitor of Mios Studio to get it  :happy: .

 

If you choose Motormix emulation and look at the direct output of the MF module in Mios Studio you can see two CCs instead of one when you move a fader. So that´s how 14bit resolution is generated. (CC a) x (CC b) = 128 x 128 = 16384 = 14bit!

 

With the regular pitchbend mode or the mackie/logic emulation mode there would only be a 10bit resolution available.

Edited by John E. Finster
Link to comment
Share on other sites

  • 7 months later...

Hi, I'm gonna dig this one back up... I'm hell bent on getting metering working here, and I have some equipment coming to help. Unfortunately, it appears that the popular thing to do in this situation is to make up an LED matrix for external metering. Well, I've seen alot of people work with it and their projects, but I think there is another way... tell me if this is absurd...

 

In the past, the only way to have real "analog" metering was to output each channel of audio to each channel, and use an "analog" VU meter, be it the needle kind or the LED kind. There's got to be another way. I am using the HUI protocol, and there is documentation showing what exact midi messages are being sent for 8 channels of metering. HUI only supports 32 channels, in groups of 8. Now, let say my DAW (Pro Tools) is outputting 8 channels of metering data via MIDI. I should be able to convert those MIDI messages to any type of message I want, but I need to get it out of the MidiBox NG and into a voltage. A variable voltage.

 

The metering data 'velocity' is what changes, so theoretically, a low velocity could output a low voltage, or hi velocity could output hi voltage to say... the AOUT NG, which would drive an analog meter. For some reason I can see this working. Any thoughts?

Link to comment
Share on other sites

Hi ibaman555

Sounds like a great NG project that you are starting! Im just not so shure what a analog VU that is converted from Digital brings on advatage...

The attack time will be delayed even more and the AOUT will defenetly smothen the small steps in between but this may not satisfy as you whant because the precisenes of the meter will be related to the digital steps that are sent from your DAW...

With midi thats normaly (please correct me if im wrong...) i think 8bit.

Even trough it will defenetly look great!

For the possability you need to ask TK. If the Matrix Metering is already prepared...

Best regards

Novski

Link to comment
Share on other sites

Thanks for the positive outlook Novski! The advantage of course would be that I would have the external metering, but as you mentioned, there would probably be the disadvantage of latency, first with the MIDI output and then any latency from the AOUT. In the same respect, I could just as easily connect an analog VU meter as well, if that was something I wanted to do. Either way, I am curious to see how this would work out.

 

I've attached a schematic of the metering circuits themselves, right now this will work if connected to an audio source. The PIC16F88 is used with CD4094's to allow anywhere from 20 or more LED's at a time on a bar graph. The other option I am trying to understand, is that since there is a microcontroller in play, maybe I could do away with the CV portion of this project.

 

Could the PIC16F88 be programmed to receive the MIDI metering data (or that data translated to serial data) instead of the actual audio to drive the meters? I personally don't know yet, but I imagine it's possible. This could possibly give me more accurate metering and reduce latency. Right now, I am converting my controllers RS232 output to MIDI and back again, so I know this is an option.

 

I hope TK has some input as well, I'm still new to all of this but learning a lot quickly.

post-16479-0-25786300-1396527272_thumb.j

Link to comment
Share on other sites

Hey all,

I am branching off of the plan a little, after doing some research regarding LED matrices. I was unaware at first, that using the Midibox NG is capable of handling a 2,048 LED matrix! Since this is possible I may truly be able to produce a viable product for those of us who rarely need it.

I am still not entirely familiar with how I would set this up, I'm still learning. Given the fact that I can chain 8 DOUTx4, I can have 32 stereo channel meters, which is most ideal. Ultimately it would be a 32x64 LED matrix. Some have said this is a cheaper and more effective approach. I will be trying this against my CV method as well.

I have a few concerns however. Using this specifically programmed matrix for metering, I would need to have consistent brightness regardless of how many LEDs are lit. And if I wanted all 2,048 LEDs lit at the same time (this won't ever happen), that needs to happen as well. I see that the DOUTx4 uses the 74hc595 as serial registers, but read that a better option for handing the current required would be the hef4794. This would require a redesign however. What are your thoughts?

Edited by ibanman555
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...