Introducing: The Bifrost (a freeware utility that beat-syncs midi devices to Traktor
Introducing: The Bifrost (a freeware utility that beat-syncs midi devices to Traktor in 64th notes)
This tutorial will teach you how to build the Bifrost yourself on any midi controller that has 16-24 buttons (with integrated leds).
It is necessary that you have a decent understanding of how to map midi controllers in Traktor, as well as, how to loop midi output back into Traktor (check out the Traktor Bible's "super buttons" section for more information on output loops)
In the most basic sense, The Bifrost is a midi router/re-translator embedded into the Traktor midi-controller interface that acts as a hosting environment which allows Traktor to send, and receive, midi to/from any device that uses the midi protocol. *I will describe how to build it step by step so that you can incorporate it into your own controller mappings.
-----
The Bifrost is actually quite simple. *All I you need to do is divide the "beat phase output" into 16 equal divisions, output them, and set up a few trackers to count the beats. *The real magic happens in the way we will organize (and visualize) our .tsi files, as well as, how we design advanced utilities that use The Bifrost to trigger actions in DAWs and other midi devices.
First, let me explain how Bifrost organizes midi interactions. *Think of your .tsi files as a physical pyramid, at the bottom we have "universal" interactions which are .tsi files that manage how Traktor interacts with all connected midi devices, above that we have "global" interactions, these are collections of devices (like modular controller setups) that operate as a single unit. *One step above "global" on the pyramid are "regional" .tsi, which are files that handle individual regions of the controller (like a "transport" or "platter" section). *Above "regions" are "local" interactions, and these are .tsi files that allow for advanced logic to be placed around just one button, knob, or fader. *At the very top of our midi-pyramid are "virtual" interactions, and these are .tsi files which aren't connected to any physical device, but instead, are separate logic processing nodes where we will send midi output to be processed in complex ways. *
Now that you have a general understanding of how The Bifrost will organize .tsi files, it is extremely important that you use the appropriate midi-object code at the beginning of your file name. *The designation (Uu) refers to universal interactions, (Ug) are global, (Ur) are regions, (Ul) is used for local interactions, and finally, the code (Uv) refers to our virtual interactions. *These designations will make sure that your midi-universe is a coherent, and ordered place where you easily understand interactions at a short glance.
The other important thing to understand is how midi "data" will be transferred through each .tsi node. *This is a little bit of an abstraction, however, I've tried to make it as logical as possible. *What makes the most sense to me is to imagine that M1 is an "input", M8 is "output" and that the midi signals flows "through" each individual modifier (from left to right). *This does limit the number of available modifiers that you can use in each individual .tsi, however, if you need more modifiers just create a "virtual" node and send the midi-data there for further processing.
The best way to describe how midi is sent to/from .tsi files is with the following*analogy...
One*useful way of visualizing modifiers is to compare them to ships sailing the ocean before radio communication was invented. Let's pretend you are sailing at night on a ship called M1 and you see the lights from a far away ship called M2.*
If you want to communicate something to the other ship, you can blink a light on and off to create a binary signal like a telegraph. *This would be similar to creating a toggling modifier,*outputting the "one" value, and looping the output back into the .tsi with an input command for M2.*However, if you and the other ship had lights in Red, Yellow, Green, and Orange, you could*send a more complex signal to the other ship because red could mean an entire sentence in binary, while every other color could translate to another whole sentence. This is what would be happening if M2*received multiple binary input commands with the "increase value"*setting, and then output a value above "one", so that value would be like blinking a green light at the other ship.
Now, that you know how to transfer midi between modifiers, let's apply the concept to individual .tsi files.* To have The Bifrost share modifiers between files we only need to organize the signals in a way that allows for you to know where the data is coming from, and going to.
To have modifiers share input between separate .tsi files we simply need to organize the signals in a meaningful way. The way that makes the most sense is to make sure that you are using the same modifier in the same way on each .tsi file. In example, if I wanted to share M2 between two layers on our "midi pyramid" I would need to have an input command in each file for M2 that would be connected to the same midi output/input. If setup with the same input definitions then you would see the exact same action happening to M2 in each file. I will refer to this as "tracking modifiers" in multiple .tsi from here on out.
