Today's Top Stories:
 NEUMANN BCM 104 GIVEAWAY!
If you’ve longed for the sound that Neumann mics have brought to innumerable hit records, now's your chance to have the Neumann sound for FREE! That's right, we're giving away a FREE Neumann BCM 104! The BCM 104 was Initially designed as a no-compromise voice-over and broadcast mic, made to excel at the top of its class. After looking at the specs we decided to experiment with it in the studio and discovered to our delight that the BCM 104 is really a great studio mic that excels for vocals, guitar and bass cabinets, kick drum, and toms. Go to www.sweetwater.com and sign up today for your FREE Neumann BCM 104!
| Recent inSync News: |
| · |
Monday, February 28, 2005 |
| · |
Friday, February 25, 2005 |
| · |
Thursday, February 24, 2005 |
| · |
Wednesday, February 23, 2005 |
| · |
Tuesday, February 22, 2005 |
| · |
View Entire inSync Archive |
|
|
 |
Sign up to receive the weekly inSync summary by email each weekend!
|
|
 |
| Pitch Bend |
| A special MIDI control message specifically designed to produce a change in pitch in response to the movement of a pitch bend wheel or lever. Pitch bend data can be recorded and edited, just like any other MIDI controller data, even though it isn't part of the Controller message group. Behind the scenes, at a bits and bytes level, pitch bend messages are actually fairly complex and appear to break a lot of the conventional rules of MIDI data protocol. Pitch bend messages were designed to be able to hold and transmit a lot more data than most MIDI messages primarily because it can take a lot of data to produce a truly smooth (as in unquantized) bending of pitch over a potentially broad range. If pitch bend messages were handled like most other continuous controller messages you would often hear a noticeable stair-stepping quality to the bends. Without going into too much detail, pitch bend messages have a conventional status byte, which is followed by two data bytes. Some MIDI instruments makes use of only one of these, while others use both, so the data is formatted in a specific way so all instruments are able to communicate and discern the intended amount of pitch bend desired from one platform to another. Fortunately all of this madness goes on behind the scenes for the most part. Most software sequencers deal with it behind the scenes. An exception would be older sequencers that may show all of this data in an event list view. In those cases editing pitch bend data can get pretty challenging and requires a deeper understanding of the subtleties. Another element to consider is that a lot of complex pitch bend data can potentially cause some MIDI log jam problems, especially when there is a lot of other controller and/or MIDI clock or MTC data on the same cable. |
 View the Complete Glossary |
| MIDI Merging |
Merging is the action of joining one or more streams of MIDI data into one. Although conceptually simple this is a non-trivial task. A good analogy is a set of points on a railway line changing to allow trains from different lines onto one. The points have to be changed quickly to prevent trains waiting or getting another crash into it and if left in the wrong state a derailment occurs.
MIDI mergers are required wherever two sets of MIDI sources are required simultaneously at one input. Some specialized equipment may incorporate merging of MIDI data with its own data, e.g. timecode to clock synchronizers.
There are three common problems associated with merging:
The Output should never be routed back to an Input, if this happens data will circulate continuously, like a feedback howl, and often the only way of stopping it is to pull the cables out.
Merging two of the same sources will produce conflicting data or strange jumping e.g. two pitchbend wheels in different positions will cause the receiving equipment to jump to the latest position. Merging two MIDI clocks will produce a composite higher tempo clock and two sources of MIDI Time Code will produce unreadable time code. It is desirable to be able to selectively filter the individual inputs to prevent this type of conflict.
Merging too much data onto one MIDI cable may result in lost data as the data buffers in receiving equipment get overloaded or lagging delay effects. The latter is more noticeable with continuous controllers and these may need to be "thinned" or scanned at a lower rate at source.
Mergers such as the M-Audio Merge 2x2 are often placed in a position within a MIDI system where all data passes through and so have to work reliably under all conditions. If more than two sources are required to be merged it is better to use a merger that can handle that number of inputs. Cascading two input mergers will produce accumulative processing delays, which may be undesirable. |
| View all 1,700+ Tech Tips |
|
