reViSiT v1.3.1 Pro for free

[chrisnash]

Harbinger:

Thanks for keeping up with the project - there are many plans to add features, so hopefully you'll find it more tantalising as the years go by. Saying that, I don't want to bloat reViSiT by packing it full of too many features. The core concept of reViSiT is that it plugs into a host, such as a DAW, and allows you to track music using the host's bells and whistles. So, whereas you lack the built-in DSP and FX found in Renoise, you can get all that functionality from the host.

As for your specific requests...

1. FULL keyboard customization (at least as deep as MPT's). Interface appearance customization is secondary to that.

I do plan to expand the customisable keys. Most of the keys that are not currently available to customise are those more closely integrated with the UI code, so it takes time to extract and abstract them.

2. FULL VSTi access and hosting. MPT has some limitations with loading VSTi banks, but recently has overcome some problems with parameter control. I'm not going backward from here.

There are no plans to turn the reViSiT VSTi plugin into a VST host. However, most hosts provide some way for you to link reViSiT's MIDI output up to its own VSTi plugins, allowing very tight control of synths, etc. I don't know whether its easy to do VST parameter automation, but this is something I'll look into. I'm also working on a side-project to develop a dedicated program, just for hosting reViSiT (thus making it standalone), which will have the ability to host other VST plugins.

3. FULL Pattern Editor display customization... The ability to hide/show channels and columns, as well as visible global attributes like channel volume and channel audio output (including plugins) would be necessary, and should be the first consideration in a tracker interface.

Naturally, the Pattern Editor is the most important part of any tracker, and a lot of improvements are planned for reViSiT's - specifically in the area of visualising what's actually going on, as you touch on.

Flexibility is important, but "customisation" will only be available sparingly. I intend to limit the number of program settings as much as possible, to limit users from having to do too much housekeeping.

MPT is a case in point, here. It offers uncountable settings to help you customise the interface. If you're like me, you probably spent ages trying to configure it just like it was in <X> Tracker; only to be ultimately disappointed because you can't get that 1:1 match. Yet, because you managed to match 90% of the behaviour, you'll end up thinking of it as a more limited, more frustrating version of the program you were using, rather than a new, different program, with its own identity.

reViSiT's current behaviour feels similar to IT2, simply because that's the reference I chose to start from, but I typically don't hesitate in changing how things work, if I (or a user) should come up with something *better*. And should it replace a clunkier part of the UI, then that part won't be kept if the only reason to keep it is that it's what people are "used to".

The forum is a good place to mention any ideas/annoyances. If people agree with you and your argument is well-reasoned, there's a very good chance it'll lead to a change.

'Hope this answers your questions!



Jojo:

I have to dash off now, but I'll try and dig out a slice of example code that shows you what VST plugins typically expect.

[chrisnash]

Jojo:

Sorry for the delay - the last couple of months have been busy ones. As promised, please find some example code below to illustrate how plugins request file dialogs from the host. The code is based on a Steinberg example from the VST Mailing List, so should represent the norm for plugins.

Code Select Expand

VstFileSelect vstFileSelect; // (create file selector)
memset (&vstFileSelect, 0, sizeof (VstFileSelect));
vstFileSelect.command = kVstFileLoad;
vstFileSelect.type = kVstFileType;
strcpy (vstFileSelect.title, "Open Module...");
vstFileSelect.returnPath  = new char[1024];
vstFileSelect.initialPath = new char[1024];
strcpy(vstFileSelect.initialPath, modulePath);
if(vstFileSelect.initialPath[strlen(vstFileSelect.initialPath) - 1] != '\\') // ensure path ends in '\'
strcat(vstFileSelect.initialPath, "\\");
if(effect->isHostVendor("steinberg")) // Steinberg expects path to include wildcards/filters
strcat(vstFileSelect.initialPath, "*.zip;*.it;*.s3m;*.xm;*.mod");

VstFileType vstrType ("Compressed reViSiT Module ", ".zip", "zip", "zip",  "audio/rvz", "audio/x-rvz"); // (native VSTR format file)
VstFileType itType ("Impulse Tracker Module", ".IT", "it", "it", "audio/it", "audio/x-it"); // (IT format files)
VstFileType s3mType ("Scream Tracker 3 Module", ".S3M", "s3m", "s3m",  "audio/s3m", "audio/x-s3m"); // (S3M format files)
VstFileType xmType ("Fast Tracker Module", ".XM", "xm", "xm",  "audio/xm", "audio/x-xm"); // (XM format files)
VstFileType modType ("Protracker Module", ".MOD", "mod", "mod",  "audio/mod", "audio/x-mod"); // (MOD format files)

VstFileType listType[5] = { vstrType, itType, s3mType, xmType,modType };
vstFileSelect.fileTypes = &listType[0];
vstFileSelect.nbFileTypes = 5;

CFileSelector vstguiFileSelect((AudioEffectX*)effect);
if (vstguiFileSelect.run(&vstFileSelect)){ // (open file selector)
// code to load file
}else{
// loading cancelled
}

delete[] vstFileSelect.returnPath;
delete[] vstFileSelect.initialPath;

'Hope this helps,
Chris

[Saga Musix]

I've just thought about this again today, what a conincidence In the meantime, I wrote a bit of code, but it does not return any data to the plugin yet.

[chrisnash]

Another option is to return -1 when the plugin calls the host's canDo function, inquiring after file dialog support (openFileSelector/closeFileSelector).

If the plugin is written with VSTGUI, then it will automatically use the VSTGUI file dialogs (which are wrappers to the OS's common dialogs).

The next version of reViSiT (1.4) replaces several of the dialogs with its own interface (for sample and instrument loading) and forces use of the VSTGUI dialogs for other situations (e.g. saving, module loading and directory selection) - so, whatever you code, reViSiT 1.4 file interaction should work in MPT.

[Saga Musix]

Getting back to this issue after a long time... I see that the current version of reViSiT use its own file selection code, so I can't test my new code anymore. Is there a place to get older versions, which still make use of the VST file dialog stuff, or could you probably compile a little example VST which requests a file, many files and a folder? I found the VST SDK to be extremely ambiguous when it comes to multiple files. And I couldn't find any VSTs that actually requests multiple files, and only reViSiT has a folder selection dialog.

[chrisnash]

The VST SDK is a bit hazy in places - however, the VST mailing list is good source of info and help (monitored by a number of Steinberg chaps). In any case, here's a link to an older version of reViSiT (0.94) with the old file handling, for you to test:

http://www.nashnet.co.uk/files/RVST094b.zip