Hints, Tips & News From The World Of Music Software
More hints and tips and tips from the software manufacturers themselves. This month: C-Lab, Steinberg, Dr T, Opcode.
In addition to Paul's cautionary technical words, the most basic and least technical reason for not daisy-chaining your MIDI devices is the so-called 'Italian factor': you know, the plateful of spaghetti round the back, and go easy on the pesto! Instead, use the 'star' system, where the Atari/Unitor/Export MIDI Outs each go to their own little MIDI Thru splitter boxes (such as the Philip Rees V3 or V10). Then each device receives a MIDI In only from its respective splitter, the signal path remains nice and clear, and there's no messing with Thrus.
The wiring (or to be more accurate the soldering) of plugs on MIDI leads gives rise to much speculation, by MIDI users of Atari computers, as to which planet the designer of that otherwise excellent computer came from. 3-pin (official MIDI) plugs never give problems: but a 5-pin plug whose outside pins (numbered 1 and 3) are soldered to their immediate neighbours (pins 4 and 5) will create MIDI weirdness (sticking or missing notes) if that cable is used at the Atari MIDI Out (port A) and is connected to a multi-timbral device such as the Korg M1 or Roland D110. The cable may be used anywhere else in the system without problems, but not as the first cable, coming from the Atari's own MIDI Out. Ideally, none of your plugs will be soldered in this way.
Paul was quite wrong in his assertion that there is no way a cable can slow down a MIDI signal: some people are convinced that if a cable gets tied up in knots, this will cause irreparable timing problems. The same people also believe that "MIDI" is pronounced to rhyme with "tie-dye". OK, I lied. There is no way for a cable to slow down a MIDI signal.
The highest 'resolution' of Notator and Creator is 384 ppqn. They can 'interpolate' (insert) their own internal clock pulses between the coarse but accurate MIDI Clocks, creating far finer subdivisions than MIDI Clocks. As Paul says, there is an upper limit to the timing advantages a high resolution gives you. The most generally useful C-Lab resolution is '768' (192 ppqn); only use '1,536' (384 ppqn) if you are using a low (sub 80bpm-ish) tempo and are not quantising, or where you perceive that the higher 1,536 resolution allows you to more gently delay/push tracks or individual events to bring them in time with the rest of the music.
We confirm Paul's reassurances regarding the transmission of MIDI data taking precedence over, say, screen updates. In principle, C-Lab programs always 'prioritise' MIDI notes, with controllers second, followed by everything else. The computer screen comes last (though needless to say, the C-Lab screen-refreshing routines are optimised for speed). While on the subject of screen-refreshing, the most extreme example of Paul's "molasses" occurs when a large amount of Sys Ex data is transmitted: the screen may well freeze for a few seconds while the Atari grunts away at transmitting the bytes at all possible speed (once the header has gone, the main body of Sys Ex data follows on as quickly as the MIDI baud rate allows, with no regard to pulses, clocks etc).
There's another interesting twist: where more than one note occurs on the same pulse (eg. where the music has been quantised), C-Lab programs transmit the lowest-pitched note first, followed by the other pitches in ascending order (you can follow this hierarchy in the event list) — it's done for psychoacoustic reasons, because the ear/brain extracts information on relative timing from low-pitched sounds.
And because MIDI is a serial killer (sorry, couldn't resist that one!), and Intensely hierarchical in nature, you can always predict which events will be sent in which order, given some background information:
• In a chord, lowest note first.
• In a pattern, track 1 first, followed by 2, 3 etc.
• In an arrangement, chain 'a' first, then 'b', 'c', 'd'.
• Between notes of the same pitch, but on different MIDI Channels, on the same pulse in the same track: dictated by the order in the event list.
• Between notes and MIDI controllers on the same pulse: notes first, thanks to the 'Play Algorithm' function in the Flags menu; if this is disabled, then notes and controllers share equal importance in the hierarchy, a situation that is occasionally required by some devices such as mixing consoles.
• Between MIDI Out ports A, B/C/D, E and F (for example, in one pattern tracks 1,2, 3 and 4 each contain a C3 at the same time position; each track is assigned to a different port, say A, B, E and F). Here, the speed at which the notes are transmitted via their respective ports is appreciably higher than if the same port were used by all four notes, since there is no queueing at the output buss. Using this information, you should spread your MIDI data load between your available MIDI Out ports to optimise the speed of transmission.
Using more than one of Export's Outputs gives you more Channels, but without the corresponding speed enhancements of the other ports; only use the extra two parts for non data-intensive, 'special case' devices (old, dubious synths, mono-mode devices etc).
C-Lab makes no use of MIDI Timecode (MTC), even in Version 3.1's Tape Control Mode (TCMI), which gives the user complete Fostex and Tascam tape recorder remote control. See Version 3.1 for details.
'MIDI choke' is virtually unheard of in C-Lab circles, thanks to the aforementioned Play Algorithm, and the other related function, Data Reduction, which intelligently thins out certain data-intensive controllers so that you still get the result you want, but without redundant data. Again, this can be disabled (before recording) if you need all the events (eg. when manipulating a data-entry fader).
Finally, MIDI, when used sensibly with a full awareness of how problems can occur, and how they can be remedied, is a far, far better thing than the old days of CVs, gates, triggers and the like. The concept of 'user-friendliness' just wasn't around in those days.
There have been a number of reports of spurious program changes occurring on certain brands of MIDI equipment when a lot of data is being output by a MIDI system. The first call the aggrieved user makes is, of course, to the software supplier, but a few simple tests will show you what is really happening.
Take a situation where a particular module or keyboard is repeatedly doing something strange, be it incorrectly changing program when no program change message was issued or hanging notes in the middle of a sequence. The first assumption you make is that the software is out to get you; well perhaps it is, but do this test first before you start making wild accusations. Firstly find the MIDI channel to which the errant unit is responding. Now insert another MIDI device, which has never shown the same fault, 'listening' on the same channel between the source of MIDI data and the offending unit. This wiring is important as some manufacturers have a bad habit of processing their MIDI thru data (this is where the nonsense about proper Thru connections causing delays originally came from.)
If the two devices make exactly the same mistake and both go bananas, the problem lies in the data that is being sent. If one unit does something strange and the other doesn't, given that they were both listening to the same data, it was the processing of the MIDI data received that went wrong. I suspect that certain devices cannot handle the full MIDI bandwidth for more than a very brief period of time without bursting their buffers.
Another problem you may encounter is that some equipment may not know how to deal with a MIDI data stream that uses Running Status. This is most uncommon these days — the only case that has come to light recently was a poorly designed MIDI interface for a old CV/gate monosynth.
You can select which outputs will use running status on Cubase/Cubeat on the MIDI Definitions page. Do not go and turn off the Running Status mode of transmission 'just in case', because this will actually mean that more of the MIDI bandwidth will be used to transmit every MIDI message in its absolute form.
The hardware devices that you connect to your computer in the course of MIDI recording vary enormously in complexity, from the humble key to the multifunctional MIDEX on the cartridge port, and the Timelock, SMP24 or your printer on the parallel port. One thing they all have in common, however, is the risk of damage if you try and connect then while the computer is turned on.
What can happen, if a device is partially connected while power is applied to the computer, is that current may flow through connections that cannot sink that amount of current until others, such as the power connections or the ground connection, are made.
Note also that the cartridge port connector on the keys and the MIDEX devices have an angled section on the nose of the connector, to aid with alignment during insertion. So until the connector is fully pressed home you cannot be certain of the horizontal displacement of the connector.
The rule is: always turn off the computer before connecting or disconnecting peripherals. It may seem like a tiresome bother to you but, unless you want to turn your hardware into a useless pile of junk, do it.
One last thing on the subject: this warning about connections was prompted by a phone call from someone who was having problems with a MIDEX unit. He was talking me through what he was doing as I gave directions, and when I said "turn off the computer and remove MIDEX," he replied that he had to put the phone down as it was difficult to hold in the little button on the back of the computer and remove the MIDEX. Luckily I managed to stop him doing it, as holding in the reset button is not the same thing as turning off the computer. It was fortunate indeed that the MIDEX had survived many attacks of this kind.
What followed was a debate about whether the two buttons on the back of the computer were equivalent. I know they are not; the reset button only grounds a few pins on certain chips inside the computer, and does not disconnect or disable the power supply in any way. If you still want to argue about it, ask yourself why the LEDs on the MIDEX are still lit when the reset button is held. Answers on a postcard please. Thank you.
• Set Mac Start-up device to Multifinder.
• Connect all MIDI interfaces.
• Install OMS.
• Put OMS INIT into System Folder
• Restart Mac
• Run OMS Setup. After searching for interfaces, install your devices (ie. your controller, expanders etc.). Drag each device over the interface to connect it. Cut irrelevant connections as desired.
• Save And Make Current under File menu — give the file a name.
• Install Vision 1.3
• Run Vision and check 'Setups — Instruments'; Vision should find all devices as setup in the OMS setup file you created.
• Choose Enable Input Devices from the Setups menu. All devices that you designated as controllers in the OMS Setup will be shown here. Vision will only listen to MIDI sources that are selected in this box.
• View Thru Instruments. Click the Thru instrument in the Control Bar to view all the Instruments Vision created from the device channels specified in OMS Setup.
To change the device and device channel to which an Instrument corresponds:
• Click the device name in the MIDI output column
• Choose from a pop-up menu of all output devices specified in the current Studio Setup document.
• Click the channel number next to the device name
• Choose from a pop-up menu of all output channels for that device
This is a useful function for adding up-to-date Instruments or defined devices and removing unused Instruments or undefined devices. If you check the 'Always Make from Studio Setup' option, Vision will offer you the chance to 'make Instruments' so that your Instruments window will correspond to your Studio Setup. (Many people find working with Instruments a lot less complicated if they never save Instruments in a Vision Setup file, and only save them with each sequence file.)
If you don't make Instruments from the Studio Setup document and you have a Vision Setup file that contains Instruments that don't match the Instruments created from your Studio Setup document, you'll have to remap device channels.
Some users of the first version of KCS Omega may experience problems with Phantom if it is placed at the end of the MPE list, and particularly if you need to remove it — put it after external programs and before other true MPE modules. Actually you should use PHSMPTE rather than Phantom unless you desperately need to sync to FSK — in this case you will not be able to make use of the new multi-port feature. To ensure absolute integrity, remember to sync up KCS at least once before using timecode in Tiger or SongEdit.
Now to KCS itself: unless absolutely necessary, don't use a ppqn resolution above 96. For most applications, this provides the best compromise between rhythmic fidelity and seeing the event lists peppered with lots of separate note off events. Also tools like the Programmable Variations Generator function best when note events are described as note ons with durations. Of course, if you make considerable use of quantising, little will be gained by using a resolution of 240 ppqn. Many people may well take issue with this concept but at the sort of tempos most people use, moving events a single clock step either way lies just about within the perception threshold of the average human ear.
Get into the habit of placing a tempo event as the very first event of Track 1; don't rely on the tempo setting in the environment page to start your music off at the right speed, especially if you've used other tempo events later on in the piece. This absolutely guarantees things starting off right, and is essential if you are locking to timecode.
Track mode doesn't permit looping tracks in different lengths, as Notator does, although you can achieve this in Open Mode. This may seem a disadvantage at first, but it ultimately allows for much greater flexibility. Let's assume that you're creating the first section of a song — set your Track Length to a suitable value, such as 32 or 64 bars, and then proceed to create a metronome or guide rhythm part on Track 2. One way to do this is in Track Edit; click on the second box at the bottom right hand side of the screen to access Track 2, and place the cursor on the first event if it isn't there already. Ensuring the cursor is under the Time column, press Invert and type the following:
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!