While I don’t expect Dreamtonics will actually see this, I figure I’ll make the post and cross my fingers anyway.
Problem summary:
Currently a project file is dependent on the dictionary being used. Custom dictionaries are a huge time-saver when using non-default phoneme mappings, however this means that if you send your project to another user or computer they must also have a copy of the dictionary or else the output will sound different.
Additionally, if you lose access to your dictionaries it is not enough to back up your svp files, because without the appropriate dictionaries the phoneme mappings will be all wrong. Most users would expect backing up the project file to be a sufficient safeguard, however without the matching dictionary files there could be a lot of work required to restore the svp to the point where it produces the same output as when it was backed up.
Proposed solution:
We should have an option to embed the dictionary mappings into the svp file. This could take two forms:
An option to embed an entire custom dictionary in the svp file itself.
A button that applies all dictionary mappings to the notes as explicit phoneme entry as if the user had typed them all manually in the piano roll.
The least elegant solution would be to save custom dictionaries to the same directory as the svp, rather than having them hidden in the user documents directory. At least this way users would see that there is a second file to back up and/or send to a collaborating party.
Edit: I would also like to propose having two levels of dictionary, a “high level” dictionary that could be used for general fixes and adjustments, as well as a “project level” or even “track level” dictionary (ideally embedded in the svp file) that could have song-specific adjustments. Ideally both “levels” of dictionary would be active in a cascading manner.
There’s a probbem with adding a dictionary to a svp. Essentially, a svp is a text file for synth v to say when , text and edits are done. It may be a bit to much to enject the dictionary to the svp. Which, is why having libraries is better. Without, having the svp get cluttered .
Because, synth V libraries are like utaus oto’s , or vocaloid ddb files. It may not be reasonable to force voice database configs into svp files. This is why I’m creating libraries to help ease the work for english singers to sing both english and Japanese Hirigana/ Romanji .
I’m sure others are trying to make similar custom libraries to help address similar issues your having . The high level dictionary you suggested already exists. Go to libries and create a new dictionary . You can than, creat a svp file to be bundles with your svp. Whcich would address some of your concerns .
I am aware. Please read the entirety of my post before making assumptions. If I didn’t know about custom dictionaries it would be impossible for me to explain the problem presented by this thread.
There’s just a small issue with methoid 2 . Assuming your just using Jpn voices it could work. But, voices like Genbu and, saki do not work with that kind of button press to match the voice. If you get into jpn to english/ chinese the button idea would not work. Since, the program would have to consider the different phonetics and language differences .
Considering , the options. just updating and releasing the voice library is the best solution as of now for the free synth v engine. I get losing the library edit can be a pain. But, for jpn voicebanks thats not much of a issue .
Heck, I created a library edit for eng banks to sing as a bilingual bank and support hirigana
Assuming the idea you had in mind. The script would need to consider and do alot of things. That even the vocaloid language convertors got wrong in most cases .
So, the best thing would be to use the custom libries and update them. So, when shared others could edit the library to better fit other vocals . That kind of work may be to much for the synth v staff ,
