This isn't a particularly pressing issue, though it has been driving me up the wall nonetheless, for admittedly petty and stupid reasons. I can survive without a solution, but if given one I will be incredibly grateful.
As many of us know, the oto limit in UTAU is a signed 16-bit number (2^15). I've made posts on other platforms about why I hold the (extremely speculative) belief that the oto limit being what it is may be the result of an error or oversight, but that's besides the point. I can explain this if needed but it's a long winded rant
I am quite well acquainted with the oto limit - I've made a few VBs that surpass it and they work mostly fine, mainly due to the fact that UTAU itself doesn't look at the number of oto lines a VB has very often, and when it does encounter an overflow error for this, it rarely, if ever causes a crash. But, it does cause issues in a few ways that really piss in my cornflakes, so to speak.
Firstly, opening the voicebank settings window can cause issues. I know that running setparam as a plugin is a workaround for these issues, but I can't be certain that end users will know that, or be able to run setparam as an UTAU plugin at all - thus locking them out of being able to access this part of the program.
Secondly, and this is the main one that annoys me, is that the size of the voicebank causes plugins like Pitedit by Zteer to crash and need to be closed via Task Manager, or in the case of the Mass Flag Editor by Zteer, produce an Out of Memory error and crash. This is a bigger issue because these two plugins are key to many people's workflows, especially the Flag Editor, as two of the voicebanks I've made that exceed the oto limit are multipitch-multiexpression VBs for VCCV or a VCCV-inspired format that rely on velocity edits. Luckily, AutoVelocity can automate these changes en masse and doesn't care about the oto limit, but I can't expect all users to use it. Having two EXTREMELY common plugins crash on you when using a VB is an issue I'd really rather not ignore.
If anyone knows a semi-reliable way I can dodge these errors, preferably in a way that means minimum effort for someone who downloads my VBs, I'd be most grateful. If not - I can just include disclaimers galore in the readme.
I could make a more efficient voicebank, however I REALLY don't want to slim these voicebanks down, since their large size is as a result of adding in a TON of built-in versatility and functionality, mainly, multiexpression and multipitch capabilities.
As many of us know, the oto limit in UTAU is a signed 16-bit number (2^15). I've made posts on other platforms about why I hold the (extremely speculative) belief that the oto limit being what it is may be the result of an error or oversight, but that's besides the point. I can explain this if needed but it's a long winded rant
I am quite well acquainted with the oto limit - I've made a few VBs that surpass it and they work mostly fine, mainly due to the fact that UTAU itself doesn't look at the number of oto lines a VB has very often, and when it does encounter an overflow error for this, it rarely, if ever causes a crash. But, it does cause issues in a few ways that really piss in my cornflakes, so to speak.
Firstly, opening the voicebank settings window can cause issues. I know that running setparam as a plugin is a workaround for these issues, but I can't be certain that end users will know that, or be able to run setparam as an UTAU plugin at all - thus locking them out of being able to access this part of the program.
Secondly, and this is the main one that annoys me, is that the size of the voicebank causes plugins like Pitedit by Zteer to crash and need to be closed via Task Manager, or in the case of the Mass Flag Editor by Zteer, produce an Out of Memory error and crash. This is a bigger issue because these two plugins are key to many people's workflows, especially the Flag Editor, as two of the voicebanks I've made that exceed the oto limit are multipitch-multiexpression VBs for VCCV or a VCCV-inspired format that rely on velocity edits. Luckily, AutoVelocity can automate these changes en masse and doesn't care about the oto limit, but I can't expect all users to use it. Having two EXTREMELY common plugins crash on you when using a VB is an issue I'd really rather not ignore.
If anyone knows a semi-reliable way I can dodge these errors, preferably in a way that means minimum effort for someone who downloads my VBs, I'd be most grateful. If not - I can just include disclaimers galore in the readme.
I could make a more efficient voicebank, however I REALLY don't want to slim these voicebanks down, since their large size is as a result of adding in a TON of built-in versatility and functionality, mainly, multiexpression and multipitch capabilities.
Last edited:
![[K] of Honor](/data/medal/1_1406930084l.jpg)
