The thing about using potentiometers and not encoders comes from the idea of making controllers that look and feel as analog as possible. Of course that leads to the MIDI jumping issue. There are a few ways to solve that problem:
1) Making the plugin to send back to the controller all parameter values as soon as you select a track. So the controller would not send any MIDI when you turn a potentiometer until it reaches the value on screen. This would be the ideal solution, but mostly depends on the plugin developers.
2) Inserting a MIDI plugin in between that "remembers" the last value coming from the controller. So the next time you select that track this plugin will block incoming MIDI messages until those messages reaches the stored value. That is, when you turn the potentiometer it has no effect on the EQ/Comp plugin until it reaches the on-screen value. In our opinion this is a more realistic solution and it's in our "to-do" list.
3) Making the controllers OSC compatible. OSC is bidirectional and plugin independent (it only depends on the sequencer and more and more sequencers are becoming OSC ready). So it looks like the right way to go and, now we can proudly announce that our controllers are OSC ready now!
4) Also we could make the controllers compatible with Mackie Control, just thinking about all those DAW's that aren't compatible with OSC yet. This is our next goal and we are working on it right now.
When using Hickory the frequency knobs seems to jump by little steps on screen. Why is that?
Well, this is called resolution (or lack of, in this case) and is a common MIDI problem: standard MIDI Control Change messages uses 127 steps which usually are enough for most cases. However, with certain parameters like frequency 127 steps of resolution are clearly not enough.
There are other type of MIDI messages that can take much more resolution, like NRPN or SysEx, and using them instead of CC messages would solve this problem.
We have made both Hickory and Dickory able to deliver CC and NRPN, but for now FabFilterPlugins ony "understands" standard MIDI CC. We have been in contact with FabFilter's team to sort this issue out, but although they have shown much interest, right now they are focused on other issues and probably they'll wait until enough people ask for it. Maybe is a good idea to ask?
In the meantime we have figured out a way to circle that lack of resolution. One is using Reaper. It happens that there is a free and HYPER USEFUL JS plugin called ReaLearn, which inserted in the input FX section of any track can be used not only to map any MIDI parameter to any plugin (and saved to a preset), but also to adjust the behaviour of any control switch/pot/button you have. So, we've made ReaLearn to limit the target range parameter: when receiving a MIDI CCH message with a full range 127 step resolution from a frequency potentiometer, Realearn limits the maximum and minimum value of frequency for the PRO Q plugin, makin 127 steps per band. Voila! 🙂 The result is knobs with smooth movements and band limited frequency ranges, just as it should be. This functionality is in our downloadable preset for ReaLearn.
Also, ReaLearn understands NRPN messages! So if you want even more resolution (meaning no significant jumps when movin the knobs) just configure your controllers to deliver NRPN messages and load this Realearn preset. That's it, now you have 1024 steps per band. Cool, right?
Another way for solving this issue is using OSC instead of MIDI, a protocol that, among other things, have much more resolution for each parameter . OSC seems to be the future for control surfaces, and fortunately more and more sequencers are implementing it. And the cool thing about it is that this solution is plugin and sequencer independent, so it looks pretty ideal and universal. As stated avobe, our controllers are compatible with OSC protocol.
Can Hickory or Dickory be used to control other plugins besides FabFilter's Pro-Q/Pro-C/Pro-L?
Of course. Although they are designed for controlling Pro-Q, Pro-C and Pro-L, both devices are MIDI controllers and can be used to control anything that supports MIDI.
How are messages routed to the plugins? Do I have to create a MIDI track and route it to the track where the plugin lives? Do I have to do this every time I change from one track to another?
Well, that's an option. But with most sequencers the MIDI messages only reach the track that is record-armed. And (at least with Reaper) a track can be configured to be record-armed just by clicking on it. So with this method all becomes very handy and there's no need to change any routing. Cool right? 🙂
Is there any method to avoid the hassle of mapping all the MIDI parameters?
Yes! We know that assigning all the Control Change messages one by one can be a bit overwhelming, that's why we've made the ward work for you :). Here are two files with the MIDI mapping preconfigured. Just copy them to:
C:\Users\<your user name>\AppData\Roaming\FabFilter\<plugin name>\
And you are done!
But if you want to do it by yourself, keep in mind that all Pro-Q 2/ Pro-C 2/ Pro-L 2 plugins have a MIDI LEARN function to make things easier.
Also, here you can find a table with the default MIDI Control Change numbers assigned to the panel switches and knobs.
Is there any Pro-Q template I can use with the EQ bands pre-configured?
Shure, that's called a plugin preset, and you can get it from owr downloads page. Just copy the file to:
C:\Users\<your user name>\My Documents\FabFilter\<plugin name>\
Can the default MIDI channels or controller numbers be modified?
We are working hard to develop a tiny application for you to modify any of this parameters (and more) in a simple way. We’ll keep you updated.
Also you can always use some intermediate software like ReaLearn (if you are using REAPER) or Midi Translator, which, among other things can transform any incoming MIDI message into anything you want.
Do I have to manually install any drivers?
No. Just plug the device to your USB port and wait for the OS to automatically install the drivers for you. Before that they will be recognized by your host.
My host is running, but it seems to ignore the controller when I turn it on. What can I do?
Any MIDI controller must be powered on before launching your host app, otherwise it will not be recognized. Hickory and Dickory are no different in that way. Because we don't work in Microsoft we can't be shure about what the reason is, but we suspect it has something to do with Windows and how it manages the drivers.
In any case, just remember: when using controllers power them on BEFORE your running your host.
Can I use Hickory or Dickory with OS/Mac?
We are PC people ;), so we don’t have any of this wonderful computers at hand to perform a detailed research. Nevertheless, we have to say that we could make a brief test using a MacBook Air with no problems at all. We will keep everybody posted about this.
I've got a FX rack in my home/professional studio and I don't know if Hickory or Dickory will fit in. How big they are exactly?
Relax, we've got you covered! Hickory and Dickory have a 19 inch x 3RU (48.26cm x 13.33cm) standard panel, with a depth of 3.5 cm. Both of them come with the necessary screrwing holes.
Which type of power supply do I need?
None at all. Both devices can be updated and powered via their USB type B connector. The messages are sent messages through it too.
What the controllers are made of?
Both Hickory and Dickory consist of a 2.5mm aluminium front panel and 3 PCB's: a big control board (Control Board A), where almost all the switches and potentiometers are allocated, a small control board (Control Board B), used for the big switches and some leds, and a main board (called Brains), where the microcontroller and all the necessary electronics are soldered.
Why Hickory and Dickory don't come with a case? Is this not just WEIRD?
Well, we’ve though a lot about that. And we came to the conclusion of get rid of it. Why?
Short answer: it's unnecessary and expensive.
Long answer: in OhMyBytes we came from the modular synth world, a beautiful place where each module came with their circuits exposed, and the only box you have to care about is the rack where everything is going to be screwed up. And as you can suppose that gave us the happy idea to get by without a case.
The thing is that Hickory and Dickory are devices designed to live in a rack, and the rear side of a rack is not usually exposed to any elements or unwanted fingering.
On the other hand and as a general rule of thumb: electronic equipment overheats. So using a case may have imply to use some kind of cooling system (like a fan, for example). And this imply more cost. In our case, even though both Hickory and Dickory have a minimum current consumption and they barely heat up, we think that the best cooling system for them is to let them be in the open air.
Last but not least: making a custom case for an electronic device like this is surprisingly expensive (almost as the rest of the circuit). And from the beginning our goal is to make quality devices as cheap as possible.