Hi AK,

Thanks for the kind words! Let me see if I can answer your questions... in detail...

• Speed, Tempo and Pattern Jump commands (Axx, Txx, Cxx) - are they still not implemented in any way? Or is there perhaps a way to set a fixed speed/tempo without these commands? I don't know whether or not they all fall into Advanced Sync features (planned for v0.88), so I am wondering at what stage they will become available.

None of these commands are currently supported. As to whether they will be ushered in with the Advanced Sync features, the truth is: I don't know either - so let me deal with them individually...
   The most important aspect of Advanced Sync is support for variable length patterns. Also with this, there will be a facility to adjust the row highlights in the patterns, perhaps so as to reflect time signatures (bar and beat boundaries) in the host. The basic sync method that reViSiT uses currently relies on constant speed and constant pattern length (including no Cxx's) - it is therefore just a case of simply arithmetic to take the host's song position and find out which pattern and row you are on. Advanced Sync will attempt to change this, by explicitly taking account of varying pattern lengths. As part of this, it will be a relatively simple modification to include support for pattern breaks (Cxx) - since these a simply ad hoc pattern length changes. Since this is no longer a case of simple arithmetic, I will have to keep an eye on the additional CPU overhead required - but up to this point the impact shouldn't be noticeable.
   Axx (Speed) and Txx (Tempo) are a different matter, since they can occur at any point in a pattern and more than once per pattern. Furthermore, and more crucially, they will affect all playback after the issue of the command. I can see the advantages of having both commands available - but though speed will very usefully allow a higher resolution of note entry, tempo's advantages are largely limited to those who want to break apart from the host's own tempo (and have two parts of a piece running at different tempi - a concept largely exclusive to contemporary 'classical' composers). Sadly it is not possible for reViSiT to dictate tempo changes to the host. Indeed, the only advantage is backwards compatibility with pre-existing IT files. And this is the quandry - as a slave to the host, reViSiT has different requirements.
   The final implementation will ultimately depend on the groundwork laid down for variable length patterns. It is possible once this is done that I will see a simple way of implementing the old commands, with their original behaviour. However, it might be the case that I also see more useful applications of these commands. Computational and pracitcal constraints might advise restricting the Axx command to multiples of two - allowing double or quadruple (etc.) the resolution. This way, the bar and beat boundaries of the host will still be guaranteed to fall on tracker rows (and not between them!). Tempo, also, might be superflous as a tracker command, being totally determined by the host - reViSiT already reacts to changes of tempo in the host at any point during a piece. So, the Txx command may not be needed. Tempo changes could be set in the host, instead - and this is how it is likely to be.
   However, these are early days. I know that many people (myself included) would like to load up their old IT modules and remix them. Therefore, it would be useful if reViSiT could support all the IT commands, and behave as IT did. So, no matter what strategy is initially implemented, there are always options for the future. For example, there could be mode where reViSiT partially decouples itself from the host's sync. Instead, reViSiT manages it's own tempo, speed, etc., but still responds to the host's Play and Stop buttons (so that you can start the sequence and the module together, e.g. when recording). This is how most trackers would sync to MIDI (e.g. in Renoise), but is not quite how I envisioned reViSiT - it doesn't best exploit the VST connection. On the flip side, there might be a method whereby one opens up the Pattern Options (by pressing F2, in the Pattern Editor) and specifies a time signature and the number of bars for the pattern, in order to determine the pattern length and ensure retention of sync with the host. And, of course, it's possible that several of the features could be implemented and manually switched by the user. The bottom line is: we will see.

• Sample loader: Are you planning to include an integrated sample loader in the future, like the one IT has? The standard "open file" dialogue certainly does its job, but one of the best features of IT is the ability to preview the samples in a directory (and their data) before loading.

Heh heh, this is going to be a shorter answer: "Yes". reViSiT will eventually boast the sample and instrument loaders (or "libraries") of IT, as internal editor pages, with full preview functionality. It should, however, be noted that Cubase hosts already include a preview option for audio files inside their dialog.

• Keyboard: It's set to Manual mode, but (for instance) when I press F1, I get both the reViSiT help screen and the Sonar help screen. Not sure if I'm doing things right...

In Manual mode, you also have to manually enable and disable reViSiT's keyboard handler, each time you want to use it - you can click the K-key icon in the bottom right of the reViSiT screen, or press Ctrl-Alt-K. This essentially has the effect of stealing the keyboard focus for reViSiT, whenever it's needed. If you are a already doing this, then it is conceivable that there is a problem with hosting situation. Sonar, being based on DirectX, must use a wrapper to support VST plug-ins. There are two that I have tested: Cakewalk's own VST Adapter; and Tonewise's DirectiXer. So, in some cases, there might be up to three applications fighting for the keyboard input (Sonar, the Wrapper and reViSiT). It is also possible that one of the 'contenders' (other than reViSiT) is using the same method to steal the keyboard input. What it might be doing is getting the the input first, using it and then releasing it back into the wild, whereupon reViSiT grabs it. Should this be the case, I can't see much hope of fixing the problem - though there might be options in the wrapper which toggle keyboard support.
   If you can't solve the problem, then let me know which wrapper you are using and try to list all of the keys that are causing problems. I'll try to look into it at some stage - though it might not be until Beta, now - finishing MIDI and cracking on with Advanced Sync is the current priority. Also let me know if you manage to solve the problem yourself.

All the best,
Chris

How people use reViSiT is entirely up to them. However, I have to admit that she is designed to be used for interpretive use, rather than compiled use. These are bastardised programming terms, so let me explain:

Compiled Use would be how you are using reViSiT currently - writing music in reViSiT, exporting it (compiling it) to an audio file, and then perhaps using the audio file in a sequencer / host project (as the drum part for a MIDI sequence). It has few advantages over using a standalone tracker, like Renoise. Indeed, under this strategy, the only remaining reason for using reViSiT is that it is perhaps one of the only IT-centric Windows trackers.

Interpretive Use delays the export phase until the very end. You write a bit of MIDI in the host, you write a drum line in reViSiT, you tweak something in the host, you tweak something in reViSiT - nothing is set in stone until you want to mix the whole lot to a CD, at which point you simply use the host's Audio Mixdown function. Perhaps you have parts of your drum beat the lend themselves more to MIDI sequencing, and parts which lend themselves more to tracking - both at the same time. With reViSiT as a plug-in, you only have to switch windows before you can tighten up a host's MIDI rhythm, or replace the tracker's samples for a phatter sound. At any point, the final output can simply be heard by hitting the play button. And, in reViSiT, you can even make changes while the song is playing back!

reViSiT is about having an integrated music editing environment, trying to keep as many options open for as many stages of the musical process as possible. And I think this will become plainer and plainer as reViSiT nears v1.0. For example, the more MIDI you use in your tracker patterns, the more you'll appreciate the facilities afforded by the host - the more the boundary between tracked parts and MIDI parts will be blurred. And when reViSiT has assignable outs, bouncing patterns down to audio files will become even less necessary (except perhaps in the pursuit of CPU power). Instead of fielding a thumping drum loop or two for a mix, reViSiT might supply half the mix itself - and the dividing line between tracker and sequencer will be so hazy, that the act of bouncing down or exporting tracked audio will be superflous.

I don't expect everyone will use reViSiT like this, but I thought it might be a good idea for me to explain my concept of what reViSiT will become, and how it will be used.

All the best,
Chris