wine and dssi-vst

Pablo · Post by **Pablo** » Fri Apr 18, 2008 10:05 pm

Hi!

Although I have installed wine from the 64studio repos, and have successfully been using some VST instruments, some others have crashed. In addition, some posts by Thorgal have convinced me that I need a newer version of wine and dssi-vst (to run Addictive Drums for example).
The problem is when my distro (64Studio) doesn't have the package up to date, then I activate the sid repository and there are a lot of dependency issues and plenty of libs that want to be upgraded... oh no! I'm lost. I have to compile from source, and that's a nightmare because I don't know exactly what I'm doing...
Anyway, I have managed to compile the latest wine version (brand new 0.9.60) and dssi-vst following their README files. But dssi-vst doesn't work because (I think so) DSSI-PATH is not set properly. But I don't know how to set it. I don't understand this:
To use dssi-vst: make sure DSSI_PATH is set appropriately, set
VST_PATH to a colon-separated list of the directories containing VST
plugins, and start up your DSSI host.
Which file have I to edit? or How do I do that?

studio32 · Post by **studio32** » Fri Apr 18, 2008 10:49 pm

I don't know much about VST, I'd rather like to find out the original sounds of linux...

But to be able to install packages from sid I've made my Debian testing/sid mixed system.... I don't know if this is an option for you..

But I've installed a rt kernel from the musix repo and followed this thread and use now only aptitude and I have good experiences with it...
But it isn't a out of the box configured optimised 64studio system... (you have been warned...)

Don't try to mix 64studio cause that's based on debian stable...

http://forums.debian.net/viewtopic.php?t=15612

EDIT: You know you can add the latest wine repo to your sources.list?

http://www.winehq.org/site/download-deb

thorgal · Post by **thorgal** » Sat Apr 19, 2008 9:09 am

Ola Pablo,

don't worry, it's not too bad. I don't have these environment variables set to anything either so dssi will default to standard paths for what it's looking for. Here is a log file from a dssi-vst session on my system :

Code: Select all

 thorgal@studio:~$ vsthost Addictive_Drums >& dssi.log

Returning file identifiers: qRGhcO77eJ64JU6a1lAAeDVC
DSSI_PATH not set, defaulting to /home/thorgal/.dssi:/usr/local/lib/dssi:/usr/lib/dssi
RemoteVSTClient: executing /usr/local/lib/dssi/dssi-vst/dssi-vst-server -g Addictive_Drums,qRGhcO77eJ64JU6a1lAAeDVC
DSSI VST plugin server v0.986
Copyright (c) 2004-2007 Chris Cannam
Loading "Addictive_Drums"... 
VST_PATH not set, defaulting to /home/thorgal/vst:/usr/local/lib/vst:/usr/lib/vst
dssi-vst-server[1]: done
Testing VST compatibility... 
dssi-vst-server[1]: VST entrypoint "VSTPluginMain" found
dssi-vst-server[1]: plugin instantiated
dssi-vst-server[1]: plugin is a VST
dssi-vst-server[1]: plugin has a GUI
dssi-vst-server[1]: plugin supports processReplacing
dssi-vst-server[1]: opening plugin
WARNING: Sample rate requested but not yet set
WARNING: Buffer size requested but not yet set
dssi-vst-server[1]: plugin is VST 2.0 or newer
dssi-vst-server[1]: plugin is a synth
dssi-vst-server[1]: plugin name is "Addictive Drums"
dssi-vst-server[1]: vendor string is "XLN Audio"
Initialising Windows subsystem... 
dssi-vst-server[1]: registered Windows application class "dssi_vst"
dssi-vst-server[1]: created main window
dssi-vst-server[1]: sized window
dssi-vst-server[1]: showed window
done
dssi-vst-server[1]: created audio thread
cannot read response from jack server (No such file or directory)
4873
4873
dssi-vst-server[1]: set sample rate to 96000
dssi-vst-server[1]: set buffer size to 1024
client sized shm to 65536
sized shm to 65536, 0 inputs and 16 outputs
Ignoring incoming sequencer event of type 66
Ignoring incoming sequencer event of type 66
Remote VST plugin audio thread: returning
dssi-vst-server[1]: cleaning up
dssi-vst-server[1]: closed audio thread
err:ole:RevokeDragDrop invalid hwnd 0x60034
Write failed on fd 12 at remotepluginclient.cpp:451: Broken pipe
dssi-vst-server[1]: freed dll
dssi-vst-server[1]: exiting
vsthost: bailing out

As you can see, I use the little app 'vsthost'. I have patched the cpp source file to my taste, so you can run more than one instance of the same VSTi without using the process ID as a unique identifier (this is a bit lame I think because you cannot conveniently save jack connections to such an app in ardour with such a volatile name but that's another matter).

Anyway, here is the "patch" if you want to recompile vsthost (it's actually the direct code, I lost the original version):

Code: Select all

int
openJack(const char *pluginName)
{
#define JACK_NAME_LEN (24)
#define TMP_NAME_LEN (21)

    const char **ports = 0;
    char jackName[JACK_NAME_LEN];
    char tmpbuf[TMP_NAME_LEN];
    int i = 0, j = 0;
    int id = 1;
    
    for (i = 0; i < TMP_NAME_LEN-1 && pluginName[i]; ++i) {
	if (isalpha(pluginName[i])) {
	    tmpbuf[j] = pluginName[i];
	    ++j;
	}
    }
    tmpbuf[j] = '\0';

    jackData.client = 0;

    do {
	snprintf(jackName, JACK_NAME_LEN, "%s_%d", tmpbuf, id);
	jackData.client = jack_client_new(jackName);
	
	// check if jackd is running
	if (system("pgrep jackd") != 0) {
	    fprintf(stderr, "ERROR: Failed to connect to JACK server -- jackd not running?\n");
	    return 1;
	}

	id++;

    } while (jackData.client == 0);

So open this vsthost.cpp file, locate the function called openJack and replace the block with mine until you hit the line

Code: Select all

    jack_set_process_callback(jackData.client, jackProcess, 0);

(this line and after should remain unchanged).

As a side note, I find the vsthost app to be better than calling jack-dssi-host directly. You can omit the .dll extension when calling the VST, and it will look into standard locations : /home/user/.dssi /home/user/vst, etc.
Note that you MUST NOT leave spaces in your dll filenames. Rename them! So Addictive Drums.dll becomes Addictive_Drums.dll, etc.

OK, that was a cosmetic thing. Now, for your dependency problems ... I started with 64studio as well, but I quickly realized it was a debian repackaged so I soon after upgraded to debian sid (that's my favorite distro). I am not sure how much of 64studio is left in my system but in my case, it had not been a problem at all. However, if you are uncertain about administrating a debian system, I wouldn't recommend the big upgrade.

Pablo · Post by **Pablo** » Sat Apr 19, 2008 12:25 pm

@Studio32:
OK, I did know but I had forgotten

. Thanx for the idea. I've added the wine repo to my sources.list. Just in case, I have uninstalled wine 0.60 and installed from synaptic wine 0.98 (Etch had 0.96).
[Edit: numbers mixed up. I had installed wine 0.9.56. I had compiled 0.9.60 and then uninstalled. The deb package from the wine repository is version 0.9.58 which is what I have now]

Yes, I prefer to stick to my distro, as Thorgal comments, I'm not very good at administrating Debian (nor any) systems.

@Thorgal

I've added your patch, thanks. Then make and the make install. THis is the output I get from make install:

mkdir -p /usr/local/lib/dssi/dssi-vst
mkdir -p /usr/local/bin
install dssi-vst.so /usr/local/lib/dssi
install dssi-vst-server.exe.so dssi-vst-server dssi-vst-scanner.exe.so dssi-vst-scanner dssi-vst_gui /usr/local/lib/dssi/dssi-vst
install vsthost /usr/local/bin

I have Addictive_drums.dll in /home/pablo/VST (yes without spaces, read it your post in the ardour forum

)

Well, I run vsthost Addictive_drums.dll . This is the error message:

Returning file identifiers: 9o1guDkYzGO6P1S88zE5sMt3
DSSI_PATH not set, defaulting to /home/pablo/.dssi:/usr/local/lib/dssi:/usr/lib/dssi
RemoteVSTClient: executing /usr/local/lib/dssi/dssi-vst/dssi-vst-server -g Addictive_Drums.dll,9o1guDkYzGO6P1S88zE5sMt3
wine: cannot find '/usr/local/lib/dssi/dssi-vst/dssi-vst-server.exe.so'
Plugin server timed out on startup: No such device or address
vsthost: bailing out

thorgal · Post by **thorgal** » Sat Apr 19, 2008 12:46 pm

which version of dssi-vst did you compile ?
which wine version do you finally run ? it is not clear from your last post (you got some strange version numbers).

Pablo · Post by **Pablo** » Sat Apr 19, 2008 12:51 pm

Yes I know why wine couldn't find
'/usr/local/lib/dssi/dssi-vst/dssi-vst-server.exe.so'

Because in winecfg I had my drive D as /home. Wine was not seeing /usr.
Now my drive D is /.
That rises the old question again. Is it safe that wine sees your root directory? I hope so.

To summarize:
I have installed through synaptic the binary of wine from the winehq repo, as suggested by Studio32.
I have compiled dssi-vst, following the instructions of the README file (make and make install). Before that, I have patched the .cpp file as suggested by Thorgal.
In winecfg, my root directory is set as drive D.
Open jack, open a terminal, cd to /home/pablo/VST, (where I have my .dll plugins), run vsthost Addictive_drums.dll, open another terminal, run vsthost StudioDevil.dll
I'm happy again!

@Studio32
I use Linux native plugins, but for instruments such as the guitar and the drums, I prefer the said VST instruments.

Thanx again for your help
Pablo

Edit: @Thorgal: Wine 0.9.58 dssi-vst 0.6
(Crossed post, sorry)

thorgal · Post by **thorgal** » Sat Apr 19, 2008 1:02 pm

this wine drive thing is a little weird.
D points to /home in my case,
C points to ../drive_c
E to /media/cdrom0
Z to /
maybe that's the Z drive you were missing ??

which reminds me of a comment I forgot to make : wine does not run as suid root, so I don't see how it could be a problem. If wine emulates the windows admin user, I don't think it has anything to do with the unix host root user. So my guess is that you should not worry about that. This said, if you are afraid to expose sensitive data form your root partition to malicious spyware that sneaked in your wine layer, I cannot say much about that but honestly, I don't think it is a big issue IF you had partitioned your linux correctly.

Pablo · Post by **Pablo** » Sat Apr 19, 2008 2:44 pm

Yes, I was missing a virtual drive that pointed to the root directory.
So right now, in my case D: is / instead of /home and I don't have Z. I don't think I need it.
In Windows drives are called with letters. Normally C: is the first hard disk. D: can be a second hard disk, a partition of your first hard disk, a CDROM drive...Depends on your hardware. You end up with as many letters as drive units. I used to be a Windows user. (not anymore) That's why I had the paranoia with wine seeing my root directory.
Thanx for your comments.
Cheers
Pablo

thorgal · Post by **thorgal** » Sat Apr 19, 2008 3:05 pm

cool! so you're all set now

I am about to finish my first song with AD, what a change ... all I did before with other drumming softs sound so flat in comparison! I really needed something serious so right now, I am spending all my time redoing drum lines ... but when you get the hang of it, it's a treat

The editing in rosegarden is quite flexible and if you're lazy, you can import AD midi files to get started, there are 3000+ MIDI beats to play with!!

Short comment about performance : I can get down to 128 buffer size without xrun, running rosegarden, AD and ardour with a few plugins (EQ, SC4, etc). When I add jamin, it takes it as well but it becomes a little uncertain, jack shuts down randomly, could be up for 2 days and then kaboom! then you restart it, and after 2mn, everything is zombified. So I have a "lazymode" in qjackctl for jamin operations (pure playback). Running in full duplex is more demanding.

schivmeister · Post by **schivmeister** » Sat Apr 19, 2008 3:14 pm

Whoa good patch I'll diff it when I get the time. It'll make for a good alternative package

Btw, I only got into VSTs not long ago. Personally I find instruments (especially strings) quite useful, since using samples I can never achieve the correct dynamics. As for effects, I feel Gear > LADSPA > VST.

thorgal · Post by **thorgal** » Sat Apr 19, 2008 3:19 pm

be careful though! I didn't like this name length a bit

it was all hardcoded in the original code and that's a bad habit. But I did not want to completely rewrite the code because I don't have time. Second thing : the author of the dssi-vst is clearly mentioning something about FIFO's and how the dssi server is not cleaning upon shutdown. The /tmp is becoming full of rplugin* stuff to be deleted by hand once in a while. Moreover, as he mentioned as well, there are "tons" of processes running in parallel so be careful not to open too many instances of a VSTi if you don't have the machine power for it. It would be nicer if you could run more than one dll within the same process maybe (?)

cannam · Post by **cannam** » Tue Apr 22, 2008 10:58 am

The next version of dssi-vst will be along shortly, and vsthost in this version will use jack_client_open (a function that didn't exist when dssi-vst was first written) instead of jack_client_new -- this should have much the same effect as the patch in the thread above.

If you have any more fixes or changes that might be of interest, do drop me a line at the address in the dssi-vst README. I do occasionally still update dssi-vst... just not all that much.

Chris

thorgal · Post by **thorgal** » Tue Apr 22, 2008 6:56 pm

Hi Chris, welcome here

I'm glad dssi-vst is evolving. I did not bother contacting you because this enhancement patch was only for myself until a new version would come out, taking into account the latest jackd API development. Any date you could tell us for the next release ? I use the 0.6 version everyday and it is more than usable! I wouldn't do my drumming so efficiently were it not for this vst host! so many thanks

cannam · Post by **cannam** » Thu Apr 24, 2008 10:06 am

I can't really predict a date for the next release -- dssi-vst is one of those lower-priority projects that is very easily preempted by something urgent coming up with another piece of work, so any estimate I give could end up being inaccurate to almost any degree. But, hopefully soon. I still have a couple of bugs to fix before release though.

Chris

Pablo · Post by **Pablo** » Sun May 25, 2008 7:32 pm

Just drop a line to remind you that dssi-vst 0.7 is already out (Chris announced it a week ago or so in the LAU mailing list. Thank you!).
It works like a charm. I run two instances of Studio Devil plus Addictive Drums at the same time with no problem.
Pablo

64Studio 32b
Linux 2.6.21-multimedia
Intel Core 2 CPU 6420 @ 2,13 GHz
M-audio Audiophile 2496

LinuxMusicians

wine and dssi-vst

wine and dssi-vst

Solved!

dssi-vst 0.7