Is it still considered preferable to have VCV and CV banks as separate downloads?

Lystrialle

Administrator
Administrator
Tutor
Supporter
Defender of Defoko
This is totally me having a "what are the kids doing these days?" moment, so you'll have to forgive me :sing:

Anyway, in 2009-2010 or so, when VCV was still quite the new thing, the ratio of CV-only users to VCV users was still quite high, and it was considered prudent to keep separate downloads for your VCV and CV banks if you could.

That is to say, rather than configure a VCV bank to support VCV and CV simultaneously, it was considered preferable to have an entirely separate download for the CV bank with its own samples and oto.ini file. The reason was that with VCV banks often being a few gigabytes in size, and with variable download speeds around the world, it was a common complaint among CV-only users that they didn't want to have to download the whole VCV bank just to access the CV.

However...2009-2010 was when download speeds and hard disk space were a lot tighter than they are now, and moreover Ritsu Kire hadn't come out yet to popularize multipitch/powerscale to the degree it's at now, so nowadays you see large-size VBs on the regular. Plus, looking at analytics, CV-only seems to be far less in demand than it was back then (when there was often a severe prejudice against VCV on principle), so while I would certainly balk at the idea of cutting CV support entirely, I'm wondering if it's still worth keeping the separate actual CV around, or whether I should just integrate it with the VCV download for organizational purposes (i.e. have a single VCV library but have it support VCV, CVVC, CV, or whatever the user chooses to use at that time).

I'm just curious what the general stance on this is, since it's not really a big deal for me to do one of these things, but there are quite a few advantages to keep a more organized download setup.
 

partial

UTAU English advocate
Retired User
Supporter
Defender of Defoko
I think if it's a bank with multiple alias types it's fine to offer it all as one VB - like a VCV vb that's also been aliased to support CV or CVVC. But if you're using a separate set of wav files for each vb, it makes more sense personally to offer them as separate downloads entirely imo.
 

AnkuruPeter

Teto's Territory
Well, if your purpose is offering various alternatives to everyone (beginners, for example), you should have VCV and CV voicebanks separately. If you want to offer a voice to experienced people, you should have only a VCV voicebank.
 

partial

UTAU English advocate
Retired User
Supporter
Defender of Defoko
Well, if your purpose is offering various alternatives to everyone (beginners, for example), you should have VCV and CV voicebanks separately. If you want to offer a voice to experienced people, you should have only a VCV voicebank.
I'd argue experienced people are more likely to want the option to use CVVC alongside VCV, even if only for VCs.
 

AnkuruPeter

Teto's Territory
I'd argue experienced people are more likely to want the option to use CVVC alongside VCV, even if only for VCs.
Yes, that's correct. It's more in line with the idea of offering various ways of use. However, CVVC is an advanced method to reduce recordings. Therefore, you can make a CVVC voicebank, compatible with CV, instead of making a VCV bank.
 

partial

UTAU English advocate
Retired User
Supporter
Defender of Defoko
Yes, that's correct. It's more in line with the idea of offering various ways of use. However, CVVC is an advanced method to reduce recordings. Therefore, you can make a CVVC voicebank, compatible with CV, instead of making a VCV bank.
I'm well aware what CVVC is and that it's intended to reduce recordings. That's why I think voices with different wav packaging should be their own downloads.
It's nice to have a VCV bank with CVVC aliases, but it'd wouldn't make sense to have its own separate CVVC style recordings on top of it.
 
  • Like
Reactions: Utaeru

Similar threads