Using Arch Linux (again, I know, unsupported distro yada yada yada) EDIT: Tested on Ubuntu 22.04 as well, bug persisted
When I chose a voicebank that supports Vocal Modes, and tried enabling Vocal Modes automation in the parameters panel, the program crashed. Tried with Chifuyu v.102, Saki AI v.124, and Mai v.100
Stack trace from gdb -ex run -ex bt synthv-studio didn’t yield anything useful aside from a segfault, which made me think if I need to update my voicebanks, but then I didn’t see any female voicebank update
Thread 1 "synthv-studio" received signal SIGSEGV, Segmentation fault.
0x0000555555c24516 in ?? ()
#0 0x0000555555c24516 in ?? ()
#1 0x0000555555982e11 in ?? ()
#2 0x000055555598c53a in ?? ()
#3 0x000055555598e6d9 in ?? ()
#4 0x000055555599351e in ?? ()
#5 0x000055555599c2df in ?? ()
#6 0x0000555555a38d7b in ?? ()
#7 0x0000555555a2242e in ?? ()
#8 0x0000555555a22f1e in ?? ()
#9 0x000055555590b419 in ?? ()
#10 0x000055555598c3d1 in ?? ()
#11 0x0000555555e5b088 in ?? ()
#12 0x0000555555f20155 in ?? ()
#13 0x0000555555ea2e5f in ?? ()
#14 0x0000555555ea3539 in ?? ()
#15 0x0000555555eb43ed in ?? ()
#16 0x0000555555eb47a5 in ?? ()
#17 0x0000555555cc3ad2 in ?? ()
#18 0x0000555555ccf321 in ?? ()
#19 0x00005555557583e1 in ?? ()
#20 0x00007ffff763a290 in ?? () from /usr/lib/libc.so.6
#21 0x00007ffff763a34a in __libc_start_main () from /usr/lib/libc.so.6
#22 0x0000555555768a3e in ?? ()
If anyone use a different distro (especially Debian, Ubuntu and their variants like MX Linux, Mint or PopOS), please let me know whether you could automate Vocal Modes or not.
(also, apparently it has nothing to do with kernel, as any attempt to automate Vocal Modes crashed SynthV on both latest 6.1 and 5.15 LTS kernel, so my guess might point to something about glibc)
EDIT: A quick test in a virtual machine running Ubuntu 22.04 also crashed SynthV, using Mai. Stack trace was more or less the same as what I posted.
Workaround: Use Windows version with Wine (preferably latest Wine staging, this way you’ll also be able to use the VSTi version via yabridge)
You’ll have to reinstall all of your voicebanks from scratch though, as Windows SynthV seems to store its configurations and paths in the exe itself. I haven’t find a way to point it to my installed voicebanks folder, yet.
Configs are in ~/Documents/Dreamtonics, symlink your voicebanks folder with databases and other configs you want with their corresponding folder. Paid voicebanks would still be treated as inactivated though, so deactivate them in your Linux installation, or keep in mind that you’re now using up 2 activation slots.
This bug persisted in 1.9.0b1 :< I’m starting to wonder whether this bug is related to my configuration or not, so please let me know if you’re using other distros and are also affected by this bug
New discover: It doesn’t affect SVPs that has vocal modes enabled from other platforms.
This is a SVP from my friend Hao-P, with vocal modes automation enabled using SynthV Pro 1.8.1 for Windows. The video showing I was able to playback, and even edit the vocal modes automation on my Arch machine: Vocal Mode automation working on existing SVP that enabled it
However, as soon as I create a new track then tried to enable vocal modes automation, it crashed.
I’ll write another email to Dreamtonics support to address this.
i’m having the same issue it didn’t work on my ubuntu install and it’s not working on my arch one either. definitely not just a you problem. i wish more companies tested all their features on linux more often
Unfortunately it haven’t been fixed for me Tried with Mai v.101b2, Saki AI v.125b2, and Chifuyu v.102, on an Arch installation with glibc 2.37-3.
Will try on Ubuntu later. Maybe I’ll target 18.04 and turned out minimum requirement is now 20.04 so 20.04 only
UPDATE: Tested on an Ubuntu 20.04 VM with glibc 2.31, SynthV Pro 1.9.0b2 and Mai .v101b2, still crashed. Backtrace seems to be a bit different compared to 1.8.1, but almost identical to my Arch GDB backtrace.
Ubuntu 20.04 backtrace:
Thread 1 "synthv-studio" received signal SIGSEGV, Segmentation fault.
0x0000555555c46596 in ?? ()
#0 0x0000555555c46596 in ?? ()
#1 0x0000555555999ea1 in ?? ()
#2 0x00005555559a3829 in ?? ()
#3 0x00005555559a5ac9 in ?? ()
#4 0x00005555559aab5e in ?? ()
#5 0x00005555559b65bf in ?? ()
#6 0x0000555555a5adfb in ?? ()
#7 0x0000555555a4413e in ?? ()
#8 0x0000555555a44c2e in ?? ()
#9 0x000055555591d439 in ?? ()
#10 0x00005555559a3f46 in ?? ()
#11 0x0000555555e7cf48 in ?? ()
#12 0x0000555555f41f85 in ?? ()
#13 0x0000555555ec4d1f in ?? ()
#14 0x0000555555ec53f9 in ?? ()
#15 0x0000555555ed62ad in ?? ()
#16 0x0000555555ed6665 in ?? ()
#17 0x0000555555ce5992 in ?? ()
#18 0x0000555555cf11e1 in ?? ()
#19 0x000055555575df31 in ?? ()
#20 0x00007ffff7720083 in __libc_start_main (main=0x555555759070, argc=1,
argv=0x7fffffffdf08, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffdef8) at ../csu/libc-start.c:308
#21 0x000055555576e58e in ?? ()
Arch backtrace (with additional info from debuginfod):
Thread 1 "synthv-studio" received signal SIGSEGV, Segmentation fault.
0x0000555555c46596 in ?? ()
#0 0x0000555555c46596 in ?? ()
#1 0x0000555555999ea1 in ?? ()
#2 0x00005555559a3829 in ?? ()
#3 0x00005555559a5ac9 in ?? ()
#4 0x00005555559aab5e in ?? ()
#5 0x00005555559b65bf in ?? ()
#6 0x0000555555a5adfb in ?? ()
#7 0x0000555555a4413e in ?? ()
#8 0x0000555555a44c2e in ?? ()
#9 0x000055555591d439 in ?? ()
#10 0x00005555559a3f46 in ?? ()
#11 0x0000555555e7cf48 in ?? ()
#12 0x0000555555f41f85 in ?? ()
#13 0x0000555555ec4d1f in ?? ()
#14 0x0000555555ec53f9 in ?? ()
#15 0x0000555555ed62ad in ?? ()
#16 0x0000555555ed6665 in ?? ()
#17 0x0000555555ce5992 in ?? ()
#18 0x0000555555cf11e1 in ?? ()
#19 0x000055555575df31 in ?? ()
#20 0x00007ffff75c3850 in __libc_start_call_main (main=main@entry=0x555555759070, argc=argc@entry=1,
argv=argv@entry=0x7fffffffe1f8) at ../sysdeps/nptl/libc_start_call_main.h:58
#21 0x00007ffff75c390a in __libc_start_main_impl (main=0x555555759070, argc=1, argv=0x7fffffffe1f8, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe1e8) at ../csu/libc-start.c:360
#22 0x000055555576e58e in ?? ()
This bug still affects me on SVS 1.9.0 with Mai v.101. on an EndeavourOS installation with glibc 2.38-3. My backtrace is similar to @dottokuya’s.
Backtrace
Thread 1 "synthv-studio" received signal SIGSEGV, Segmentation fault.
0x0000555555c47cd6 in ?? ()
#0 0x0000555555c47cd6 in ?? ()
#1 0x000055555599b291 in ?? ()
#2 0x00005555559a4c19 in ?? ()
#3 0x00005555559a6eb9 in ?? ()
#4 0x00005555559abf4e in ?? ()
#5 0x00005555559b79af in ?? ()
#6 0x0000555555a5c53b in ?? ()
#7 0x0000555555a4575e in ?? ()
#8 0x0000555555a4624e in ?? ()
#9 0x000055555591e839 in ?? ()
#10 0x00005555559a5336 in ?? ()
#11 0x0000555555e7e688 in ?? ()
#12 0x0000555555f436c5 in ?? ()
#13 0x0000555555ec645f in ?? ()
#14 0x0000555555ec6b39 in ?? ()
#15 0x0000555555ed79ed in ?? ()
#16 0x0000555555ed7da5 in ?? ()
#17 0x0000555555ce70d2 in ?? ()
#18 0x0000555555cf2921 in ?? ()
#19 0x000055555575e221 in ?? ()
#20 0x00007ffff7427cd0 in __libc_start_call_main (main=main@entry=0x555555759360, argc=argc@entry=1, argv=argv@entry=0x7fffffffe3c8)
at ../sysdeps/nptl/libc_start_call_main.h:58
#21 0x00007ffff7427d8a in __libc_start_main_impl (main=0x555555759360, argc=1, argv=0x7fffffffe3c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffe3b8) at ../csu/libc-start.c:360
#22 0x000055555576e87e in ?? ()
That being said, I think this bug is entirely unrelated to glibc (as its symbols are only mentioned at the bottom and are all related to calling the entrypoint of the executable).
Edit: another workaround is to manually edit the .svp file. This takes some skill – you have to edit the vocalModes property of the note group. Insert the following key–value pair into the map for each mode you want to insert, replacing <name> with the vocal mode name:
"<name>": {
"mode": "cubic",
"points": [0, 0.0]
}
I also tried using a plugin to call NoteGroup.getParameter with vocalMode_<name>, but this crashes SVS as if you did it through the UI.
I’m collecting information to send off a bug report to Dreamtonics about this issue as it seems to be a ongoing issue. Have you (or anyone else) used the current 1.11.0b1 update and still have it crash?
Any further details you can provide would be useful as well.
For me that’s a non-starter as a workaround. Wine introduces far too many dependencies; and while I use a Windows VM from time to time, I do so only when client contracts oblige me to use Microsoft Office. My workaround for the moment is to have e.g. six tracks, with gradually varying mixes of modes and move between them. It’s a pain in the neck. I use Linux (Mint 21.3) on principle; and using a Windows application in an emulator (by any other name) violates that principle! So, for example,
Track 1: Solaria: Soft (0%) Passionate (100%)
Track 2: Solaria: Soft (20%) Passionate (80%)
Track 3 etc etc
In extremis that may mean that each consecutive note or phrase is on a different track. That’s a lot of unnecessary additional work, but it works. I used it to produce a very classical-sounding track from what is basically a pop voice bank (i.e. Solaria). As an aside, a “Classical” vocal mode would be a welcome addition, I could supply you with the set of parameters that I use if this idea appeals.
I’d be happy to try that; if it works, I’d have thought that it would be easy enough to code such a mod into the SVS app. So are you suggesting (a) format the .svp file as per your subsequent comment and then (b) edit the formatted file to include the code you describe? Having said that, if the code were open source, I’d lay bets on the dev community solving the issue fairly quickly!
it didn’t work on my ubuntu install and it’s not working on my arch one either. definitely not just a you problem. i wish more companies tested all their features on linux more often
Tried with Mai v.101b2, Saki AI v.125b2, and Chifuyu v.102, on an Arch installation with glibc 2.37-3.