Hey @Sam_Pluta
I’ve been using your oversampling oscillators in a project and am loving them. Thanks!
I noticed that VarSawOS plays at 1/2 the frequency (latest release, Windows build). Is that a known issue? It’s pretty easy to work around, but maybe also easy to fix?
(
{
var oscs = [VarSaw, VarSawOS];
oscs.collect({|v| v.ar(2) });
}.plot(1);
)
There’s also a little jump at initialization with most (all?) of these oscillators. Seems to cause some nan explosions if not managed carefully in a wildly modulating environment (I wasn’t - fine with old skool oscs, not fine with these).
I’ll check out the VarSawOS tomorrow. That is really weird.
Are you saying that they do blow up? They really shouldn’t. The hickup is the filter getting warmed up. Let me know.
Sam
Thanks. They do blow up. I managed to blow them up all day 
. I was able to reproduce blow ups and compare with stock oscs, which did not blow up. Each of the three OS Oscs I’ve been using - SquareOS, SinOscOS, and VarSawOS - suffered, no matter the oversampling value.
Unfortunately for diagnostics, these were all rather complex situations with a lot of routing / bus mapping. I was not able to create a simple example with a nan slam. It seemed that at least part of the cause was switching bus mapping while a synth was playing. I think I’ve gotten around the problem by performing the remapping after an s.sync, but it really doesn’t seem like it would have mattered, value-wise. I’m reluctant to send you down a rabbit-hole on info this diffuse, though.
Uploading the VarSaw fix. I found 3, count them 3 bugs in the code. One was a “how did this ever work” bug (divided by 0 error).
Looking at the code, the only way I can see it blowing up is if your frequency is somehow 4x the sample rate. Is that possible? Maybe it is something else, but that will do it. However, it will just get stuck at 1 or -1. It should get out of control.
OK. I think I see the solution. Luckily I use the same oscillator core in all of these.
I can’t count how many days have ended with me thinking, Finally wrapped this one up, only to fire whatever it is up the next day and find ten glaring things wrong with it.
The frequency was clipped between 0.1 and 20k, and polling showed everything in range until sudden nan. But, tell you what, if I happen to be able to reproduce the problem in an easily communicable way, I’ll post it. Until then, let’s call it a me problem (that I think isn’t a problem for now, anyway).
like now when I just committed my changes with a fucking cout in the audio loop?
1 Like
fixed it (and more characters)
1 Like
Btw, I think that I figured out the cause of the blow ups, and it was not (really) these ugens. I’m using a somewhat novel scaling for fm that requires linexp, and it turns out some zeros snuck in. I was clipping the frequency down the line, but that was too late. The stock ugens seem to take the attitude of What’s a little nan between friends? but the OS ones were having none of it. Seems a fair position to take.
Yeah. If the internal phasor somehow outputs a nan, then that value is going to be sent to a lowpass filter, and the filter is going to freak out. So I imagine that is what was happening.
Sam
1 Like
