Could that large negative number be a NaN (not a number). I ask, because of a problem that I spent months trying to track down had similar symptoms. The NaN output from the problem module could affect downstream modules. The problem would come and go. The problem turned out to be an out of bounds array index. You might put the Voltmeter on the output and watch that. With my problem, it would display a very large number that was far wider than the Voltmeter panel.
Cheers for your reply man , I’m in acoustic blues mode at the moment but I’ll be firing up my computer later and do some more testing. I’m not a programmer and don’t really understand the concept of a NaN, I assume it is the some operation such as the square root of a negative number that gives an invalid output. I can tell you though that the pulse was pretty large extending well beyond the voltage range of the oscilloscope so you might be on to something. Could this have something to do with running in Rosetta mode and some line of code hasn’t been translated properly. I will post again when I have some more news.
NaN just means that the byte representation of the number is invalid. It is probably just garbage. Different modules handle invalid input voltages in different ways or not at all. Others have talked about this in other topics. The symptom is that if you put the Volt Meter module on the output, you may see millions of volts;)
I’m on Windows.
Have you had a chance to look in the log file to see if anything weird is being logged?
IMO, an array index overrun is the most likely cause of such a problem. But, all sorts of things can corrupt memory. If it is an array index problem, in my case the problem only showed up when running the sequencer module in reverse order and was thus an edge case that was difficult to track down.
I’m sure Bret can figure it out if you are able to show that garbage voltages are coming out of the Groovebox.
Very interesting. I’m wondering if perhaps it’s an integer of floating point number that peaked so high that it rolled over into negative territory. Later today I’ll take a close look at the delay code to see if that’s somehow possible. I’ll also ensure that it has bounds checking in place to avoid the array index overrun. Happy to help! I’ll post my findings!
1 Like
Are you using floats or doubles? I’m sure you are aware that it is very easy to under-flow or over-flow the float range, necessitating using doubles in some types of serial calculations.
@k-chaffin Yep, that’s a good thing to note. I’m using float for most of my audio calculations, and I’m wondering if some of the delay math is causing an overflow. Here’s my delay code, and I can already tell by looking at it that it could use some defensive coding additions! (And comments 
)
@lawnland Could you send me the samples that you’re using? I’m wondering if there’s anything unusual with them that could be causing issues.
I have tried using lots of different samples from lots of different folder all are mono 44.1kHz 16 or 24 bit files. I did what K-chaffin suggested and put a voltmeter on the output and when I move any delay control it outputs a voltage so big it overflows out of the end of the VM display and almost off the end of my screen so I think he may be on to something. What I’m going to try next is uninstalling an re-installing the groove box and see if that makes any.difference. Btw I looked in the log and nothing suspicious just the modules I added and the autosave logs. I am just adding this as I’ve had look in the VCV Rack rack folder and I cannot see how to safely just uninstall the groove box as the structure looks different to the other developers . I did notice that a Voxglitch.json file was added at the bottom of the VCV Folder on the 7th September and is 27 bytes if that means anything.
There’s an interesting part of my code that relates to the delay effect:
It’s assuming that the left and right buffer both exist. In essence, it’s assuming that the samples are stereo. Of course, that’s not ideal, and I’ll need to revisit that code. However, in the meantime, could you do me a favor and see if the issue occurs with a stereo sample?
Also, if you wouldn’t mind sending over an example of one of your mono samples, I’d like to see if I can recreate the error by using it. I want to rule out the possibility that your samples are somehow causing it to burp. I’m very sorry for the bug. I’ll keep on it until we get to the bottom of it! I don’t think that a reinstall will make any difference though.
If we can’t figure it out by the end of tomorrow, I’ll add some code that clamps the output of the delay to reasonable levels and we can give that a shot. 
I"ll try it with a stereo sample later today. Is it possible to add an attachment to a VCV Community post and if not what is the best way to send you an example of my samples. Regarding stereo samples, as the unit excels at been used for drums samples and that the majority of them are mono it would make sense that the groove box could read mono samples. Thanks again for your time and effort and for the modules that you provide for VCV irack, in my future virtual eurorack adventure I’m sure I will get to use most of them.
Can replicate the delay being horribly broken in latest official update on 2.12 Rack Pro on an M1 Mini. Mono or stereo sample does not matter, touch the knob in Delay FX section and run for the mute button ;). Tried with different lengths first set, still no dice,. all else seems fine though
Does the Shift / Cmd Scroll Wheel functionality work on your mac mini to navigate through the folder containing the samples.
I wholeheartedly agree. I definitely will ensure that mono samples are supported. I’m just trying to narrow in on the issue. Feel free to email me the sample at clone45@gmail.com.
I’ll try to make time today to walk through the code line-by-line, looking for possible clues. I may also be able to add some code that clamps the output to reasonable levels, which might at least stop it from crashing rack. Thanks for your patience!!
As fractalgee has confirmed the problem on an M1 mac the chance that his and my samples are causing the problem is unlikely, I will still send you the samples if you want but I don’t think it will solve anything. I have tried many different samples from multiple sources and they all show the same problem. Still cannot my head around the fact that on one occasion it played with no problems whatsoever.
I agree, but there’s no hurt in testing! Would you have time to try with these drums? I fully expect that you’re correct, but I just want to double check. I’ll start scouring the code later this afternoon for other possible causes.
PS: My current thought is that I don’t fill the arrays used for the delay before I start accessing it. Perhaps the “undefined” arrays act differently on the various platforms.
ah yes, that is broken too, scrolls around the Rack window
No it exhibits the same problem, Nice Kick drum b.t.w I’ve added it to my kick drum folder and named it KICK_clone45. All the computer speak goes over my head I’m afraid. I wish I’d spent a bit more time when I was younger to learn how to code. I spent a lot of time writing BASIC programs on a Commodore Pet but when someone showed me Cobol I thought this is not for me.
No worries. I really appreciate you taking the time to try that.
I have made adjustments to the delay which hopefully will solve the problem. The unfortunately thing is, since I’m not on a Mac, I can’t create a build for you of the new code, so there will be a delay before you can try it out. I hope to get a new bug fix build submitted to the library within the next day or so, but it takes some time to go through VCV Rack’s build system.
For those following along who are developers:
The first change that I made was to ensure that the arrays were full of actual data and not random “stuff” in memory. I’m really hoping that this was the culprit.
SimpleDelay()
{
for(unsigned int i=0; i<MAX_BUFFER_SIZE; i++)
{
buffer_left[i] = 0.0;
buffer_right[i] = 0.0;
}
}
Secondly, I replaced this:
if (read_index < sizeof(buffer_left))
with…
if (read_index < MAX_BUFFER_SIZE))
… which shouldn’t make a difference, but was cosmetically better IMHO. Maybe sizeof() was lying to me? Ha ha ha.
Thirdly, I clamped the output to -100.0 to 100.0:
// Defensive programming in case the audio explodes for some reason
read_audio_left = clamp(read_audio_left, -100.0, 100.0);
read_audio_right = clamp(read_audio_right, -100.0, 100.0);
Fingers crossed!
2 Likes
Thank you for your time and effort. To me the way that this has been handled is how a community forum should work with benefits for both the developer and the end user. If you ever need a beta tester for anything now I’m retired I have a lot of time on my hand, give me a shout. I look forward to trying as and when the new version is in the library.
3 Likes
Wonderful! It’s my pleasure, and I really appreciate your help. I sincerely hope that the changed I made solve your issue, and if not, I’ll keep on it!
IIRC, different OS’s can handle implicit initialization differently. I know that there are some differences in C and C++ in this regard. Also different compilers may handle this differently.
It is probably a wise thing for all developers to do explicit initialization of arrays, where possible.
1 Like