Perhaps the most important thing to keep in mind when using MusicWonk is that it is always active, always live. This is different from most notation based MIDI sequencers, where there is a distinction between editing the piece and playing it.
Like most Windows programs, MusicWonk has several timers for time events. However it also has 3 special timers, based on the high resolution Windows Multimedia timers, that run the module execution loops: the main run loop, and the Clock1, and Clock2 run loops.
Essentially, the loop timers are set to a repeating time interval, and when each timer fires or "ticks," MusicWonk wakes up, processes all its modules, then goes back to sleep again until the next timer tick. This places a much heaver burden on the CPU than standard MIDI editing programs that only run in response to a user event, or when playing or recording do little additional per-note processing. In this respect MusicWonk is much more like a SoftSynth than a MIDI Sequencer.
Main Loop module calculation
When the Main Loop timer fires, MusicWonk starts calculating modules from the first module in the Start, or root, of the Module Tree in priority order. Thus, starting at the top level page (where the System module lives) the first module in the chain. labeled "A" - which normally will be the System module - is calculated, then the next in the chain, labeled "B," and so on until all modules in the top level are calculated. Then the Main loop timer goes back to sleep.
What makes things interesting is that when a macro module is encountered, it opens up a new level to be calculated because the macro module has within it another list of modules, also in priority order relative to that macro level. Macro modules may contain other macro modules, which can contain more macro modules, etc. So instead of getting a simple A, B, C module execution, you get a recursive run through the tree, which you can illustrate by fully opening up the Module Tree and following the root lines of the macro modules.
Fortunately this is not nearly as complicated as it sounds from the description above. You only need to think of the module run loop as it applies locally to the current macro level you are working with. For example if you are at the top level, you only need to consider the priorities of the modules on that level. From the local level, macro modules appear and are treated just as any other module.
Clock1 and Clock2 module calculation
The Clock1 and Clock2 execution loops are different from the Main Loop. These timers cause only macro modules that are set up as Clock1 or Clock2 macros to execute, and these macros do not execute at all in the Main Loop.
When a Clock1 or Clock2 timer fires, it starts with the first Clock macro it finds in the main loop run list, and continues to recursively execute any modules contained within it, in a similar manner as the main loop run. These are exclusive to the Clock that triggers the module. That is, Clock1 modules are run exclusively by the Clock1 timer, Clock2 modules by the Clock2 timer. If you put a Clock2 macro inside a Clock1 macro, the Clock2 macro will run, but it will run only when the Clock2 timer fires, it is ignored by the Clock1 run loop.
How it actually works is, when MusicWonk gets a Reset flag, it first runs through the module execution tree in recursive order as described above, and extracts the run address for each of the Clock macros it finds, and puts them into a local execution list array for each of the 2 Clock timers. Then when the Clock timer fires, it only runs the macros on its list and any modules (including any non-Clock macros) contained in the Clock macros.
Note that if you put a non Clock macro inside a Clock macro, the non Clock macro executes inside the Clock macro only, and it is never seen (and therefore does not execute) when the Main Loop run cycle is run.
You can set the Main Loop timer to any interval from 1 millisecond to 1,000,000 milliseconds (16.7 minutes) in Windows 2k or XP, somewhat less in Windows 95/98. You cannot shut it down except when slaving MusicWonk to external MIDI. You can shut down Clocks 1 & 2 by setting them to 0. After shutting them down, you must do a Reset to start them back up again, it is not enough to just change the time to a non zero value. All 3 timer loop intervals can be set from their respective inputs in the System module. The System module also has outputs for each loop that shows the loop count since the last reset.
In general, and unless you have specific reason to do otherwise, Loop timers should not be set much below 10-20 milliseconds. Setting the timers faster than this may cause timer overruns, which will result in audible MIDI timing glitches. Timer overrun is indicated by the red LED in the lower right of the Status bar. It is normal for this to flicker when files are loaded or saved, or at the very start of a Reset or Load, or just prior to recording a MIDI file. This is because MusicWonk does considerable pre calculation prior to starting its timing loop runs in order to make the actual module calculation loops as efficient as possible. Overruns at these times have no effect on the loop timing accuracy.
Loop Intervals and Tempo
MusicWonk timers are set in milliseconds (1/1000th of a second), but music, including MIDI uses BPM or Tempo for timing. Additionally, musical notes are timed relative to the tempo, not absolutely. So a the actual time of a quarter note will be nearly a half second (480 ms) at a tempo of 125, and a full second at a tempo of 60.
The MIDI standard reconciles this by setting the MIDI clock or "tick" interval to a floating time of 24 ticks per quarter note, and the tempo to a set time stated in microseconds (1/1000th of a millisecond).
MusicWonk adheres to the MIDI standard of 24 ticks per quarter note. This gives about 20 milliseconds between MIDI ticks, which is plenty time to calculate even the most complex set of modules, and to get back to sleep so your soft synth can use up the lion's share of the cpu cycles.
When you attempt to set the Tempo in MusicWonk in milliseconds (there are modules in the Process menu to translates tempo to milliseconds and milliseconds to tempo), you will find that the millisecond settings per tempo at 24 ticks per quarter note have considerable rounding error. That is, 20 milliseconds gives a tempo of 125 BPM, but the next increment, 21 milliseconds, gives a tempo of 119 BPM. Tempos 120-124 have been lost in the rounding error.
While you are free to bump up the clock rate for finer resolution and then increase the ticks per quarter note accordingly, as a practical matter this is rarely necessary. The times where you really need smooth tempo transitions, as when implementing accelerando and ritardando, you generally will get better results by incrementally changing the Duration setting of a Free Run Clock, than by upping the run loop rate and changing the Tempo.
And when you are using MusicWonk to process real time MIDI input, for example to produce Karma-like arpeggios and riffs in response to your keyboard playing, then you do not use the loop timer at all, instead you use direct MIDI processing that is independent of the loop timer.
MusicWonk's philosophy of timers
Because MusicWonk needs to use as little of the computer's CPU resources as possible in order to coexist with soft synths which are generally much more CPU intensive, there are some trade offs and limitations on how MusicWonk runs its loop timers.
The two main concerns are 1. that the loop timers are accurate, and 2. that minimum CPU resources are used. The conflicting issue is the necessity for MusicWonk to fully calculate each module in the run loop each time a clock ticks. An additional concern is for MusicWonk to peacefully coexist with other Windows programs, not grabbing the processor while they are busy, potentially causing instability.
Putting all this together requires some compromise. In MusicWonk the compromise is this: MusicWonk's timing events are relatively low priority to Windows and even to many other applications such as soft synths. The trade off on the up side is you get rock stable dependability in performance venus where crashing is not an option. However on the downside, while MusicWonk timers are normally highly accurate, when you interact with Windows by, say, moving a window or loading a large file, the timers can loose accuracy. The exception is that when using the MusicWonk MIDI recorder, the MIDI events are always recorded accurately (the timing values are calculated and therefore do not depend on timer accuracy), and the MIDI file you create will be free of timing errors even if some occurred while making the recording.
When using MusicWonk in live performance, we recomend using a MIDI live controller such as the Behringer BCR2000. MusicWonk has full MIDI NRPN support as well as direct input support with its Array Sliders for easy to implement live multimedia control.
Additionally, there are two settings in Global Options that will reduce the sensitivity to Windows GUI events. One is "Use Fast Clocks" which allows MusicWonk to grab the timing critical multimedia timer messages ahead of other events; the other is "Run High Priority" which increases the priority of MusicWonk relative to Windows. How effective these settings are and - more importantly - whether they cause instability when MusicWonk is overloaded, varies greatly from computer to computer. We recommend you enable "Use Fast Clocks" (the default) and disable "High Priority" (also default), however as in all things MusicWonk, you are encouraged to experiment and use what works best for your setup.
MusicWonk is Copyright © 2003-2010 by John Dunn and Algorithmic Arts. All Rights Reserved.