Home » The PARIS Forums » PARIS: Main » Paris VST/DX issues
|
|
|
|
|
|
|
|
| More information mined! [message #105167 is a reply to message #105155] |
Thu, 08 April 2010 09:14   |
drfrankencopter
Messages: 137
Registered: July 2009
|
Senior Member |
|
|
Ok, I'm getting somewhere with Senderella now.
It turns out there is a trick to getting it to work with Paris...with only limited testing this is working for me:
(1) The 'silence tracks' (note, that they don't need to be silent, at least in my re-write of senderella) on the return need to be 24 bit (when used on EDS submixes)
(2) The transport 'now-line' must be started well inside all send/return objects. There are problems when object start boundaries are encountered. On some plugins this gives a 'click', on Senderella this introduces a latency on the return. I'm trying to fix this now that I've narrowed it down a bit.
(3) Send/return objects must be continuous (maybe crossfades will work...still needs investigation)
(4) It needs to be wrapped to DX...I suspect this is due to the way paris handles stereo VST's, but I may be wrong.
One of the downsides with (2) is that if you rewind to zero time on the now line (double press rewind button on the C16), you will pass the now line over the start handles for all objects, and Senderella will go out of sync.
And, another discovery:
After getting senderella to work with zero latency (got a perfect null with phase reversed send/return on a single EDS submix), I tried putting the send on EDS submix 1, and the return on EDS submix 2. I could not get a null, but got close (within a few samples) I haven't counted the exact sample delay, but I suspect it's the 9 (is it 9?) sample submix 2+ delay that was identified a few years ago. This would seem to suggest that the delay comes from the EDS mixer itself, and not from the way the tracks are spooled up in the editor window.
I've got a bit more investigation to do, and will continue to report my findings in this 'blog' style.
Cheers
Kris
|
|
|
|
|
|
|
|
|
|
| Re: More information mined! [message #105180 is a reply to message #105177] |
Sun, 11 April 2010 11:51 |
drfrankencopter
Messages: 137
Registered: July 2009
|
Senior Member |
|
|
Ok, now I'm really getting somewhere...
Found out some more nuggets about Senderella and Paris:
Regarding 16 bit and 24 bit files:
1) 16 bit source (send) tracks will work fine with 16 bit 'silence' tracks for the return.
2) 16 bit source tracks will work fine with 24 bit 'silence' tracks for the return.
3) 24 bit source tracks will work fine with 24 bit 'silence' tracks for the return.
4) 24 bit source tracks will work fine with 16 bit 'silence' tracks IF the returns are on a native submix.
5) 24 bit source tracks will not work right with 16 bit 'silence' tracks if the returns are on an EDS submix
Regarding object start handles, crossfades, etc:
1) 'return to zero time' can be easily re-set using the locator. Doing this will allow your double rewind press to bring the 'now line' to a position other than the far left extent of the editor window playing field.
2) Crossfades in a send track will result in timing errors on the return...even if the crossfade is full length, and seemingly continuous. For that matter the Paris 'tape' tool refused to see the splices as continuous either...
3) Track #1 is the most picky about the start handles @ time zero on the editor playing field.
Latencies with Senderella:
1) Send on EDS submix 1 to return on EDS submix 2 = 14 samples
2) Send on EDS submix 1 to return on EDS submix 3 = 12 samples (seems odd....)
3) Send on EDS submix 1 to return on native submix 4 = 12 samples
4) Send on EDS submix 2 to return on EDS submix 3 = 2 samples
5) Send on EDS submix 2 to return on native submix 4 = 2 samples
Regarding the FXPansion VST/DX wrapper:
1) It will not save your parameter settings, unless you define at least one program. This would have only affected early releases of Senderella.
Regarding Paris, DX & object edits:
1) Paris uses a block size of 2000 for DX plugins.
2) When paris encounters an edited object (or more correctly an end handle) it will send a smaller block to the plugin. (This is not abnormal)
3) When paris encounters a new start handle, it will always a block of 2000 samples, even if this sample block technically doesn't line up on a 2000 block chunk with respect to the other tracks (This IS abnormal). Because of this, the audio sent to the VST/DX chain on that track is no longer in sync with other tracks that have no edits. The result ends up being okay in the Paris mixer because Paris keeps track of the timing offsets, and corrects them after the VST/DX chain is processed. That's fine for normal DX/VST plugins, which don't communicate to one another, but it wrecks havoc on Senderella. I suspect this is also the reason why stereo DX/VST plugins don't like some edits.
4) Paris does not send sample position, or any other useful timing information to the VST/DX chain. It only reports tempo, time sig, and sample rate.
Unfortunately, because of 3 & 4 above, there are some serious limitations to Senderella in Paris that cannot be addressed. I've tried real hard, but can see no way to handle object start handles/edits because of the way Paris handles them. BUT, at least it can be made to work in a mixdown situation, once all edits are rendered to a continuous file.
I'm moving on in development, and trying to build up the feature set that I want, including latency compensation, and available delay in the send path (for source dependent pre-delay on reverbs).
Cheers
Kris
|
|
|
|
|
|
| Re: More information mined! [message #105182 is a reply to message #105181] |
Sun, 11 April 2010 13:30 |
|
|
Kudos, Kris, for pushing the parameters like this - besides the promise Senderella has in and of itself, I wouldn't be at all surprised if some of the fundamental research you're doing breaks new ground for other development too, especially with that kind of methodical documentation.
I think it's pretty cool that now even experienced users can find new things to explore in PARIS once again!
"... being bitter is like swallowing poison and waiting for the other guy to die..." - anon
[Updated on: Sun, 11 April 2010 13:57] Report message to a moderator |
|
|
|
| Re: More information mined! [message #105191 is a reply to message #105182] |
Tue, 13 April 2010 18:36 |
drfrankencopter
Messages: 137
Registered: July 2009
|
Senior Member |
|
|
A little more research tonight....
1) If you take a senderella send from submix 2 and return it on submix 1, there is 1986 samples of latency.
2) If you take a senderella send from submix 3 and return it on submix 1, there is 1988 samples of latency
3) If you take a senderella send from submix 3 and return it on submix 2, there is 2002
samples of latency
This is interesting, but also not surprising. The reason for this is that Paris processes its channels is a submix by submix fashion and with a single thread. Thus, by the time the thread gets to submix 2, submix 1 has been processed, and any audio sent to the Senerella 'return' must wait until the next block of samples to be processed. Since Paris uses block sizes of 2000 samples, this explains the latency values that we are seeing. Note that the sample delays in cases 1,2, and 3 above relate nicely to the early latency readings that I got, but with a twist.
1) for the send on submix 2, and return on submix 1, the latency was 1986 samples. For the opposite (send on submix 1, and return on submix 2) the latency was 14. Conveniently, 1986+14 = 2000.
2)for the send on submix 3 and return on submix 1, the latency was 1988 samples. For the opposite way around the latency was 12. Conveniently, 1988+12 = 2000.
3) For the send on submix 3 and return on submix 2, the latency was 2002 samples. For the opposite, the latency was 2. Conveniently, 2002-2 = 2000.
It's a little puzzling as to why case 3 needs the latency subtracted to equal 2000...but I can think of a couple of theories as to why this happens.
At any rate, to distill this down, what it means to the Senderella user is "Have your returns on higher numbered submixes than your sends".
My whole rationale for investigating this was to look at inter-submix latency compensation within Senderella. But, I'm not going to compensate for latencies of around 2000 samples (about 90 ms). So instead, I'll just suggest to have your returns on higher submixes than your sends.
Speaking of latency compensation, I'd also like to add a slider to allow for compensation for parallel processing delay. I was thinking of allowing for up to 65 samples of delay compensation there. My reason for choosing 65 is that several plugins on this chart http://www.kerrygalloway.com/WikiPARIS/wikka.php?wakka=Nativ eLatencyDatabase have a latency of 65 or less, and this arrangement would allow for a RenComp + SSL Buss Comp. I don't want to go much higher since the slider for it could become difficult to control for getting precise values. I hope this won't be a problem for folks....let me know, your opinion counts!
Cheers
Kris
|
|
|
|
| Re: More information mined! [message #105219 is a reply to message #105181] |
Mon, 19 April 2010 18:47 |
mikeaudet
Messages: 476
Registered: February 2009
Location: Canada
|
Senior Member |
|
|
Hi Kris,
There are way to ask the PSCL for the current time in samples, if that helps. You just need to import the PSCL. I'm pretty sure the functions are exported. If you need a hand, I'd be happy to help you with it. Shoot me an email. mike at mikeaudet dot com.
All the best,
Mike
|
|
|
|
Goto Forum:
Current Time: Mon Nov 25 13:31:43 PST 2024
Total time taken to generate the page: 0.03193 seconds
|
The PARIS Forums
Search
Help
Members
Register
Login
Home
