Post by nic on Jan 22, 2019 8:44:54 GMT
Morning supadom,
Yes, there is a bit of latency involved, but 500ms sounds rather high. For starters there is inherent latency when using an AU as each AU gets called to process a 'window' of events about every 11.6ms. So, 2 StreamByters will give you a starting latency of 20ms. That's the price of using AUs, I'm afraid. BlueVelvet has configurable latency for detecting the taps and you can change this yourself. Right at the top is this line:
ASS K0 = 05 05
05 means 50ms and there are two timers. At 50ms BV checks for a single tap or a hold and at 100ms checks for double/triple taps. You can fiddle around with these.
Did you add that +D100 that I mentioned in a later post to the StreamByter 1 rules? If so, this will also add some delay between the note on and note off. I chose 100ms because I found that in AUM, low numbers were crashing both plugins (no idea why yet), but this will be after the 1st blue velvet timer. Ideally we don't want this delay.
It is possible to setup things to filter direct and BlueVelvet PCs to bypass BlueVelvet for specific PCs using a 3rd StreamByter, but:
Having said all that, it will be worth your time using MidiFire instead of StreamByter for this job, for the following reasons:
- no AU latency and CoreMIDI routing/processing is lightning fast in MidiFire
- you will be able to have some PCs sent to loopy directly without going through BlueVelvet really easily
- no issue with that +D100 we need to add to stop odd crash
I will PM you a promo code shortly because I know MidiFire is a much better bet and I'm willing to put my money where my mouth is!
I can them email you a (mostly) preconfigured Scene for this if you like too.
Regards, Nic.
Yes, there is a bit of latency involved, but 500ms sounds rather high. For starters there is inherent latency when using an AU as each AU gets called to process a 'window' of events about every 11.6ms. So, 2 StreamByters will give you a starting latency of 20ms. That's the price of using AUs, I'm afraid. BlueVelvet has configurable latency for detecting the taps and you can change this yourself. Right at the top is this line:
ASS K0 = 05 05
05 means 50ms and there are two timers. At 50ms BV checks for a single tap or a hold and at 100ms checks for double/triple taps. You can fiddle around with these.
Did you add that +D100 that I mentioned in a later post to the StreamByter 1 rules? If so, this will also add some delay between the note on and note off. I chose 100ms because I found that in AUM, low numbers were crashing both plugins (no idea why yet), but this will be after the 1st blue velvet timer. Ideally we don't want this delay.
It is possible to setup things to filter direct and BlueVelvet PCs to bypass BlueVelvet for specific PCs using a 3rd StreamByter, but:
Having said all that, it will be worth your time using MidiFire instead of StreamByter for this job, for the following reasons:
- no AU latency and CoreMIDI routing/processing is lightning fast in MidiFire
- you will be able to have some PCs sent to loopy directly without going through BlueVelvet really easily
- no issue with that +D100 we need to add to stop odd crash
I will PM you a promo code shortly because I know MidiFire is a much better bet and I'm willing to put my money where my mouth is!
I can them email you a (mostly) preconfigured Scene for this if you like too.
Regards, Nic.