|
|
| Re: Aux behaviour for Senderella project: Opinions requested [message #105084 is a reply to message #105083] |
Sun, 21 March 2010 15:18   |
|
|
-30 to +10 seems more useful than +/-20, though I could live with less range (if I want to do more profound gain trimming I'll do it elsewhere).
Saturation? What kind of saturation are we talking about here and what would it sound like? My first instinct is that there are many other ways of generating that if desired, but I guess it'd depend.
Maybe the conceptual key is making it behave like the rest of PARIS, ie "forgiving".
"... being bitter is like swallowing poison and waiting for the other guy to die..." - anon
[Updated on: Sun, 21 March 2010 15:21] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Aux behaviour for Senderella project: Opinions requested [message #105110 is a reply to message #105109] |
Mon, 22 March 2010 14:57 |
|
|
Hi Dimitrios - yep, by permission of Senderella's developer, Kris is working on a version of Senderella more customized for PARIS use. First stop is getting the pan and gains in musically useful increments.
By the way - I was thinking of organizing your previous tutorials into the same sort of illustrated "step by step" tutorial shape as this for the Wiki, would that be OK with you?
Incidentally - Senderella isn't the only thing that's gone open source and is thus available for tweaking for PARIS-friendliness - so has Wormhole. So there's new and fun avenues to explore. We could use more coding eyes on all of this though, if there's folks out there that are interested.
- Kerry
"... being bitter is like swallowing poison and waiting for the other guy to die..." - anon
[Updated on: Mon, 22 March 2010 15:00] Report message to a moderator |
|
|
|
| Re: Aux behaviour for Senderella project: Opinions requested [message #105111 is a reply to message #105110] |
Mon, 22 March 2010 18:17 |
drfrankencopter
Messages: 137
Registered: July 2009
|
Senior Member |
|
|
Hi Dimitrios,
It was your posts that inspired me to try Senderella, and sure enough it worked. But, there are little issues that bug me with it. So, I found a copy of the source code to an older version, and contacted the developer (ModuLR) and asked if he minded if I branched his code. ModuLR was more than happy to let me hack at his code, and here's what I'm working towards:
1) Send volume to be in dB instead of % (I never like working in % for audio)
2) Integrated pan knob that follows the Paris pan behaviour. I managed to get this working tonight (at least in Reaper....I haven't tested on my Paris rig yet). This means that it's no longer necessary to use 2 instances of senderella (set to different channels) per channel in order to get a panned signal.
3) Latency compensation. Here's my idea...on a return instance, there will be a slider that allows you to delay the direct pass-through path of the sends by the selected # of samples. This would let you insert say waves Ren-compressor on the return, and delay the sends to match its 64 sample latency.
4) Variable delay on each send instance...this could serve as a variable pre-delay for a reverb send. I've always wanted to have different pre-delays on different instruments in order to 'place' them in different spots in the reverb...and now it's possible.
5) Bug fixes...the source code is pretty messy in spots, and there is code in there that will never be executed. I understand the original was never really considered anything more than a hack.
If you've got some feature requests, let me know....
Cheers
Kris
|
|
|
|
|
|
|
|
|
|
| Re: Aux behaviour for Senderella project: Opinions requested [message #105123 is a reply to message #105121] |
Fri, 26 March 2010 05:30 |
Dimitrios
Messages: 1056
Registered: August 2005
|
Senior Member |
|
|
Hi,
NICE !
One thing is that edstransfer should be 8,8 or 8,16 the latter working better with disk transfer on many audio tracks.
I suspect though that this edstransfer might overheat cards.
I had a couple burned out that might be of that cause but could not either...
I have also read from other posters that this eds transfer might overheat cards...
So better have plenty of ventilation to blow some good air right on the cards.
Senderella must be wrapped. Chainer was right so ffx4 as you say is ok too BUT ffx4 is DX so you have the 64 plugin limit !!
Chainer is vst so there is no 64 plugin limit there...
Regards,
Dimitrios
[Updated on: Fri, 26 March 2010 05:33] Report message to a moderator |
|
|
|
| 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
|
|
|
|
|
|
|
|
| Re: Aux behaviour for Senderella project: Opinions requested [message #105136 is a reply to message #105131] |
Sun, 28 March 2010 21:02 |
drfrankencopter
Messages: 137
Registered: July 2009
|
Senior Member |
|
|
Learned a whole ton about Paris' native FX oddness this weekend.
1) Paris tells VST plugins that it is using a 1024 sample block size (comparable to an ASIO buffer size, it's the size of the data 'chunks' that Paris passes to the plug-ins). BUT, Paris actually sends 2048 as the number of samples to process. What's even more strange is that if you look at the actual samples that are sent to be processed, it's only the 1st 2000 that actually contain data, and the final 47 are all zeros
2) I ran into all sorts of problems running a send and return on the same submix. I was running the send on channel 1, and the return on channel 3/4 and I was getting stuttering sort of sounds. I fought with these sounds all weekend, and made no headway. But, out of desperation I tried moving the returns to a native submix, and VOILA....the problem rectified itself, and the return audio sounded just fine. My best guess is that there is an order of operations issue that needs to be worked out, and the moving the returns to the native submixes fixes it as they are processed last.
3) The plugin behaved very differently when wrapped by FXpansion versus under Paris' native VST host. The paris implementation was unpredictable at best.
Cheers
Kris
|
|
|
|
|
|
The PARIS Forums
Search
Help
Members
Register
Login
Home
