As TroubledMind found, not quite fixed but not as extreme as original, so fix did something, but it still glitches, breaks up, whatever you want to call this with bursts that ovberdive audio into serious distortion territory. Not ear-shredding but not as pretty and smooth as should be
I’ve just been playing with this a bit more, the patch can be simplified to make it act strangely but I noticed something odd - as soon as I select an output from the audio module the noisy bursts start but if I close Rack and reopen (meaning it opens the same thing with the audio module output already selected) then it plays fine. The ‘effect’ is inconsistent though, one time there was constant noise between -10v and 0v and other times it plays like this (not sure if this is expected or not):
However, the original problem with huge outbursts is coming from the negative voltage in the trig input. You can use an offset module to make it happen, it seems to start when the input is around -7v and if the voltage is then changed to >0v.
It does, as it seems that Windows is unaffected with the fix in place. The poster is a mac user so I started there, but now I know that it happens on linux as well.
I simplified the patch while I was testing my fix - the poster said the same thing, it’s intermittent and would go away for a bit after reloading the patch. His patch on my machine only had bursts on channel 4 yet his patch would put out bursts on channels 1, 3 and 4. I don’t get why the same patch acts up on different channels on different OS’s.
I’m going to push the fix I’ve made at some point but it looks like I need to do some more investigation. For the technically inclined: my bug fix clamps the output voltages to +/- 5v which is the levels for Rack audio. It still doesn’t tell me why the patch suddenly, at random intervals, puts out massive spikes of around -1200v.
I watched your video, in the last half the sound is somewhat how it should be, although you’re not using a SEQ to move the notes around as in the posters test patch but the sound should be smooth like that.
I haven’t noticed that, thanks, that’s something I can possibly use for an additional fix. The code I changed just clamps the outputs, I hadn’t thought of looking at what the inputs are when the bursts happen.
I think there might be a bug either in Rack or in the Audio module. I’ve seen other odd behaviour when opening a patch without an output selected. I saw it with ZZC clock, if a patch is opened without an audio output selected none of the buttons work (same with Clocked) but if you enable an output and then delete the audio module it still continues to work.
Was the reporter’s patch made initially in v1? I think I experienced it when I opened my old template in v2 but typically I can’t reproduce it now.
Don’t know actually, I’ll ask on the issue tracker.
Are you using Rack v2.0.4 as I am? The fix is good there, it seems everyone is on v2.0.3 still, - I know 2.0.4 is still pre-release atm. The reason I ask is that 2.0.4 has this fix and am wondering whether this might help at all.
I am on 2.0.4 as well so doesn’t seem to fix the problem with Rainbow. It is odd though that I can only reproduce it by opening the original patch and enabling the audio output. I’ve tried to reproduce it from scratch in fresh/blank patch, even without an audio module, and can’t make it happen.
Here’s another interesting story in our little saga: I went back and downloaded his original test patch - because I had saved it on my machine after setting the audio device so I wouldn’t have to do that each time I loaded the patch. I’ve also downgraded Rainbow to v2.3.3 and tried these two procedures:
I’m loading his patch, selecting my audio device, then hitting the run button on the clock. Bursts occur.
I load the patch, select the audio device, exit Rack - so the patch auto-saves, launch Rack again so the patch is already there, the audio device is, obviously, already selected in the Audio module, hit run on the clock. Smooth as ice!
If I reload the patch with an audio device already selected, I can’t get these bursts to happen at all, the patch is smooth as it is in my video. I simply can’t reproduce this if I reload the patch before hitting Run.
My present conclusion: it’s the Audio module’s fault not Rainbow’s.
yep, tried that here too, you are correct, has something to do with what order things initialise in between adding audio interface to patch, and opening patch from autosave
Forgot to mention here that when selecting the device in the Audio module I also had to change the sample rate to 44.1K (already selected in the Engine menu) from 48K every time. Seemed to keep wanting to go back to the default 48K setting.
That’s not an issue for me as I use jack and there isn’t an option in the Audio module to change it but maybe there is something going on before initiation.
I think so, that’s what the consenus opinion is in that other thread. You tested in the same way as I have, @ fractalgee above said they did the same thing, got the same result.
I built Rack v1 from source, for v2 I’m using the SDK, so it might be time to look a bit closer at the v2 source and see if something stands out in the audio module and/or rtaudio code.
