WHEN IS A MERGE NOT A MERGE?
Good question. When is
a merge not a merge? When it is a true multi-input system, of course. Some people seem to be confused about the difference between parallel MIDI In sockets and merged MIDI inputs. The difference is slight to most users, enormous to others.
This all came about from the warning I gave about using a MIDI merge box as a 'poor second' to manufacturer specific hardware (ie. MIDEX
) when connecting the Fostex MTC1 to the Cubase
system. To recap, the MIDI Time Code emanating from the MTC1 needs to be 'seen' at the input of the computer at the same time as any new MIDI data if you want to record new music in sync with the Fostex. I had various enquiries about this comment, ranging from the interested to the ill-informed (rude and wrong). I shall elaborate.
You should all know that MIDI has a finite bandwidth. There is a very real maximum to the number of events per second that can be transmitted down any particular MIDI cable. With a MIDI merge box, apart from the inherent delays involved in even passing events through, two finite bandwidth systems cannot have their contents squashed into the same bandwidth without queuing buffers, prioritisation, or redundancy systems fooling about with your data. If you have ever had some of your note offs rendered redundant by a MIDI merge box you will know exactly what I mean.
It is quite wrong to assume that the same arguments apply when you use a manufacturer's specific piece of hardware with multiple MIDI in sockets. These sockets are working in parallel with each other. At no time does any compromise have to be made about what should be kept/have priority/be thrown away, because the computer can deal with these sockets at a very much higher rate than MIDI could ever send the data, and
there is no need to make 2 (or 3, or 4, or 5) into 1 fit.
So back to the Fostex example, the reason why the MIDI merge box was a 'poor second' is that in a busy system either your new notes or the MIDI Timecode will be displaced by the other because of the normal merging activity itself. There is another aspect to all this: there are merging devices on the market at the moment that don't even know what MIDI Time Code is! I mentioned prioritisation earlier; most MIDI merge boxes perform a rather more complicated task than a simple 'first in/first out/buffer the rest' when merging. They have a list of importance of events, and realtime messages such as MIDI clock have prominence over note data etc. This is all well and good, and it works adequately most of the time, but these systems tend to have an 'any other business' level at the bottom of their priorities. This allows for any MIDI bytes that the merger doesn't have in its list of specific data types, and this is where the problem lies. If your MIDI merger was designed before the advent of MIDI Time Code (and the same is true of some later designs too), it may deal with the most important data (MTC) with the least urgency, simply because it does not know any better.
My view on MIDI merge boxes remains that they are a poor second to parallel inputs, but are a necessary evil in some situations. I would recommend that you try before you buy, and do some tests in realistic situations. You only have yourself to blame if your test for correct operation is that the LEDs flash when your gloved pentadactile limb hits the keyboard.
CANON BJ10 PRINTER
This value-for-money little 'laser-quality' bubble-jet printer is supported by Notator if you set its DIP switch number 7 to ON and select the (default) NEC P6 printer adaptation. The resolution is 180 dpi. Notator does not (yet) support its high resolution — let's hope that will be along in due course. It would mean, like the DeskJet's, having a separate printer adaptation.
A very small number of printers do not like the Speeder function which is active in every Notator printer adaptation. If it looks like your printer should be compatible with one or more of the many adaptations provided with Notator, yet it appears to behave oddly, try switching the Speeder off. Your printing may be a little slower, but it should prove reliable.
FIX QUANTISE FUNCTION
This quiet little function is easily overlooked (being a keystroke, not a menu item), but is an absolute boon where you have recorded a track and wish to give it a certain swing — say, Groove 16C. What sometimes happens is that the Groove timing correction appears to be all over the place. This only occurs where you have played somewhat out of time with the beat — quite easy to do if the mother/master keyboard is fully-weighted (a Rhodes MK80, for example) and you are not anticipating the beat slightly. If you find that going straight to the Groove value gives weird results, then quantise the track to straight 1/16ths, use FIX QUANTISE (press the 'F' key), then proceed to use the Groove value. This invariably helps in the above situation. What FIX does is to make the straight 1/16ths the 'highest resolution' for that track: it can no longer go back to 768. This makes its timing more reliable for the further Grooves, where it was a little too far out for the Groove to know what it was you wanted.
DEQUANTISING A GLISS
You have recorded a Notator/Creator track, in the middle of which is a glissando: you wish to quantise the track, but not the gliss. Here, you should quantise the track as usual, enter its event editor (press 'E'), find the gliss's first note, click it and press 'F1', find the gliss's last note, click it and press 'F2'; then press Alternate + 'P' to open Process Data (or use the Functions menu) where you will find the notes' positions already entered. Now select '768: ON', switch the Limit Positions to ON, and press Return. Done. This uses the program's ability to reverse the quantisation back to your original timing, but limits it to a certain segment.