| Re: Aux behaviour for Senderella project: Opinions requested [message #105125 is a reply to message #105123] |
Fri, 26 March 2010 09:34   |
drfrankencopter
Messages: 137
Registered: July 2009
|
Senior Member |
|
|
Ok, I learned a few things last night.
1) I managed to get VSTMonitor to work. This is a plug-in that is provided with the VST SDK. I probably shouldn't distribute it, but it will help the community learn more about the Paris VST configuration. So, here's the download from my site (This link will not be left active for more than a couple of weeks).
http://web.ncf.ca/fk824/paris/VSTMonitor.dll
I'd ask that folks who're interested in getting Senderella working well in Paris install VST monitor in their system (it can be easily un-installed later by deleting the dll file). What I'm interested in seeing is the block size that different paris configuration settings use. The way to look for this is to insert the VST monitor plug-in on a channel, click on the 'Display' button, and look for an entry that is like PROCESSREPLACING(2048). Here, 2048 is the block size that paris is calling the VST plug-in with.
I'm curious to see if the EDSTRANSFER setting has something to do with the VST blocksize or not, or perhaps it's affected by Disk I/O size. I'd do this all myself, but since there's a re-start of paris required for each setting change it's a long process. If other folks can just run VSTmonitor on their setups, and tell me what the blocksize is, then it'll be faster (and I won't need to test extreme values).
2) I installed my built version of senderella into the Paris VST path, and it while it certainly did something, it was not as promising as the results were in Reaper (which I was testing on a different machine too). I was not getting stereo returns, and the audio was 'stuttering'. My current suspicion is that this is a multi-core problem, as the Senderella source code puts no protection on the shared data between plug-in instances, and relies on the Host to determine the order of processing. So, you can conceivably run into a situation where if the load gets split between multiple cores, that the returns get processed before the sends, and the buffers are empty. I'll need to do more analysis to see if this is the case.
3) Paris VST does not call the 'process()' VST function, but rather calls 'processReplacing()'....I found this out by setting breakpoints in the code, and found that no breakpoints in the 'process()' function were ever executed. Getting breakpoints enabled in the code executing within paris was a bit of a breakthrough...but the data contained in the shared memory buffer (the data shared between Senderella instances), did not look like what I expected, nor did it look like what it did when I tested in Reaper. This behaviour may be different when wrapped...I'm not sure, and it will need to be tested.
4) My dx-vst wrapper expired...I bought FXpansion 3.0 eons ago, but lost the activation code. I understand it's free now, does anyone have the link?
Cheers
Kris
|
|
|
|
The PARIS Forums
Search
Help
Members
Register
Login
Home
