Specifications

converter 1.5
2000 - 2005 urr Sound Technologies Inc.
97
tips to ensure best speed / performance
As with any complex system open to many different configurations and applications, there are certain
factors which can influence converter’s performance. While converter should provide satisfactory multi-
channel audio to midi real time performance on any Pentium 100MHz or faster, there may be individuals
attempting the use of multiple audio channels in combination with several other conversion input
sources (or other complex applications for converter) on slower machines (such as a 486) looking for
ways to squeeze some extra performance out of their configuration. As a summary of issues discussed
in this manual which potentially affect the speed or response time of converter in live performance, the
following tips and suggestions are designed as a general guideline for those wishing to improve
performance on a slower machine.
Figure out what your particular machine’s speed is capable of with converter
; avoid
overloading the computer by trying to do too much at the same time. Specifically, if speed is an
issue:
Try using the midi-only or audio-only core input modes instead of the simultaneous audio and
midi input modes in order to provide a higher guarantee of reliability, lower response times,
and lower processing overhead on slower machines
Disable the audio filters / filter channels if they are not needed – these take significant cpu
power for slower (486, Pentium 60MHz) machines
Disable the gameport input (realtime settings menu) if it isn’t being used – again, proper
gameport interface routines take a consistently generous amount of cpu time, mostly in terms
of a wait-state (due to the inherently cheap, ancient, and poor design of the IBM analog
gameport interface). Even though the gameport routines within converter have been designed
in the most efficient way possible (and they should not interfere with the timing of midi data),
there is still a certain unavoidable load this interface type places on the host computer.
Disable the lfo generators (realtime settings menu) if they aren’t being used. These
do
add an
additional computing load, which although minimal, may be significant on slower machines.
Under more extreme situations, you might try setting the screen update option (root -> display
settings) to minimal.
Do not use the vertical refresh interrupt option.
Use the ‘Hardware & System Settings’ or ‘Audio and Filter Settings’ display panel ( [F11] or
[shift]+[F11] ) instead of the oscilloscopes display panel [F10] which requires much greater cpu time
than the other display panels.
Monitor the midi bandwidth generated by converter by checking the midi data rate meter in the
hardware & system settings view screen (F11). Remember that midi’s bandwidth (number of bytes
it can transmit per second) is about 3000 bytes – typically keeping it under about 1500 or so is
usually a good idea.
If converter’s performance is less than desirable, it often has to do with
the density of the midi output stream
(number of midi bytes which are required to be transmitted
every second). Reducing the output midi stream density can be performed by making greater use
of the audio data reduction algorithms if many channels of continuous controller audio to midi
conversion are being used, reducing the number of LFOs being used (if several LFOs are
programmed to generate their own midi data streams), disabling gameport input, and the like.
Monitor the computer’s processing load by checking the processor buffer peak meter at the upper
left of the screen – it should never be ‘maxing out’ constantly (even though the buffer’s actual ‘max
is much higher than the peak meter’s max position).
As a last resort, disable screen updating and see if that improves the situation by entirely disabling
the real-time graphics.