Whysynth stops functioning when I play a note with a patch using any “Async Granular” oscillator (the preset patch DragonPurr uses this oscillator). I then have to reload the whysynth instance to get it to make any kind of noise at all.
Interestingly, I found a workaround - by running plugins in sandbox mode, Async Granular patches work fine… But this means very slow loadup times as I wait for all the ladspa plugins to be separately loaded.
James
I’ve noticed this bug in other hosts, too. I think qtractor and ardour gave the same behaviour. It’s a bug in whysynth, I believe, and not in renoise. I even tried finding it, recompiled whysynth with different parameters, but got distracted by other things along the while. I haven’t yet really debugged this beast on binary level, only strolled around the sources. I think it might be a stray pointer messing up info somewhere where it’d kill the whysynth engine. It seems naively programmed at some parts, anyway. Interesting that you’ve had success with sandbox mode - random success or permanently? I’ll try that soon. The more parameters to when the bug happens, and when it doesn’t I have the easier it’d be to track down the problematic code.
The strange thing is that whysynth sometimes doesn’t trigger that bug. The bug is very noticeable by suddenly making a plop and doing strange audible dc stuff, and then whysynth won’t make any sound anymore at all, unless plugin is reloaded. I’ve been able to sometimes actually use the dragonpurr patch, but most of the time it blows instantly. I’ve even encountered pure wavetable osc’s to blow up the same way, no granular action involved at all. Regardless of host. Instant trigger also seems to be “gaussian” windows on the granular osc, above a certain (short) window length. Other window types didn’s blow up so far for me (apart from the seldom experienced effect for crash on wavetable oscs).
What’s your system config? Mine’s at ubuntu 14.04 at 64bit, and all sources of whysynth I’ve tested had that behaviour, be it from official package-sources to self compiled “recent” versions. Let’s track this bug down - I’m currently eager to learn about synthesis, and whysynth seems an easy target, as it features little prebaked stuff and has pretty clean sources. xsynth plugin from the same makes gave no problems for me so far.
And yes, I like whysynth, though it sounds a little cheap sometimes, compared to other more sophisticated softsynths using tenfold the cpu time for the same musical load…
Hi! Yep. I think whysynth is very nice. The main weakness in my opinion is the filters but those can easily be supplemented with the renoise native ones.
I have basically the same system as you - Ubuntu 64 bit, and I have not seen the bug in qtractor (though not tested extensively). The sandbox workaround seems stable -tested for 30 mins yesterday - and quite different from non-sandbox behaviour - instant blip and no sound in 100% of tests.
Oh - by the way, I am using a hand-compiled version of qtractor so not sure if this bug may be present in the Ubuntu native version…
Yes I’m using the qtractor Version from ubuntu 14.04 repos (an old one I guess). And it blips away with dragonpurr instantly. Ardour is of course bollocks, because it doesn’t seem to support dssi, it’s been a while since I had researched that. I’ll try with muse as soon as I get time to figure out how to setup and use that beast.
Also thanks for the tip about sandboxing plugins - yes, then whysynth won’t blow up ideed! That’s a strange fact. My naive guess on what could happen is that maybe somewhere in whysynth some critical value can be overwritten, leading to blipout somewhere else. Maybe different types of initialisation of the plugin could lead to differently fragmentet/positioned memory blocks (whysynth malloc’s a lot in it’s setup), triggering the bug sporadically, but with certain high robability for gaussian agrans in conditions given from renoise unsandboxed and the qtractor version i’m using. It might be real hard to catch that one. And as i’ve said, sometimes (rarely) the bug doesn’t happen unsandboxed for me, or very similliar (blip after a few notes) with wavetable oscs.
The way this one is coded makes it hard, I’ve seen several places in the pipeline where percalculated/stored values from data structures were used indirectly to address write-to positions. Maybe something like valgrind might help, though I think it can’t really check against overwriting “legal” memory positions close to the original target.
But I’m already dreaming of smashing up obxd and noisemaker into particles and recombine the modules to something equally flexible as whysynth, enough oscs, routable juicy filters, modulation mayhem… 