a friend asked me to make him a haas-effect plugin with some little extra steps. I did it and it works perfectly fine in my DAW, cubase artist 9.5.5, but in his DAW, fl studio he gets a lot of weird clicking noises, as if some discontinuity occurs in random intervals. Iām just wondering how stuff like that can happen in general. I mean I didnāt even use any delay implementations of JUCE. I just very traditionally put samples into a vector, while getting samples from another part of the vector (circular buffer), nothing special and especially nothing that should produce different results in different DAWs or even operating systems. (Both of us use windows though, so at least thatās not a problem)
At the beginning I tried to rewrite some parts of my code to look more readable and added some safety-things like clearing all channels >= 2, which definitely helped a bit (for some reason, not sure why) but now iām at a point where iām really out of ideas what else to try there. Iām glad heās a friend, but what if he was a customer? How do you debug things, that are not happening on your own machine? Is there anything you can tell them to do to give you more valuable information? I wish i could just open the project on his computer and DBG a lot of things from there but he doesnāt live near me and obviously that also isnāt a good strategy with customers later in my career so I should get into the habit of whatever you will recommend to me in this post!
FL Studio (like a few other hosts, but not all of them) tends to split the block to smaller sizes, is it possible you assumed in your code the block size was constant between processBlock() calls?
for every block (processBlock) i used buffer.getNumSamples() to determine the length of the sample loop.
btw: huge thanks that you wanna help me with this example in particular. if you also have some ideas how to troubleshoot issues like that in general thatās great too and iād like to encourage everyone who reads this to participate in this post if you either have an idea about this specific problem, or the general problem how to deal with crossplatform issues
Which basically means in your case: are you sure that you are allocating a circular buffer FOR EVERY channel that you have, and that, for every one of those channel, you are writing and reading samples from the corresponding buffer?
Because if you are dealing with two channels, and you process the first (reading and writing from a circular buffer), and then process the second (by reading and writing from the SAME circular buffer used for the first channel), thatās probably NOT what you want.
Other from that, isnāt FL Studio available for a limited time evaluation? If so, you can start the demo of FL Studio and hopefully reproduce then debug the issue your friend is seeing.
If it is not, you can contact its manufacturer directly and ask for a Not For Resale copy of FL Studio for the purpose of testing plug-in compatibility
i indeed only have one delay object in my code, but donāt stop reading here yet. i figured no one who uses a haas effect would ever want to automate over the center, because that sounds ridiculous and i mean, most people use haas effects just statically anyway. so i thought: why not save some cpu here? so i declared a variable that can be either 0 or 1. depending if the delay parameter is positive or negative that variable is flipped. when it comes to processing the sample then that variable controls which channel writes into and reads from the delay. soā¦ there is a clicking on that transition, yes. but thatās not my problem. my problem is that there are clicking noises while staying within one channel, even long after 0 has been crossed and the buffer is not much longer than 20ms as well.
also please remember: the problem does not occur on my own system. if i was using a processor incorrectly with 2 channelās data, iād get a problem on my system as well.
I treat the samples as a single stream, so it doesnāt matter how long each block is to me.
Like āeyalamirā said, FL Studio can send really small blocks to your processor. Iāve seen it as low as 1 sample. Yes 1 sample!
It means you have to be prepared for buffer.getNumSamples() to be 1.
Your calls seem to be OK, but where is chDelay set?
It seems like youāre using the same delay line to process each channel instead of separate ones, so you should probably do delay[chDelay].process()
BTW, It would be easier on the CPU to pass pointer to a memory block of samples for the delay process, and let it run through each channel block, one at a time, to be wary of memory cache scrubbing.
As described above I only use one delay processor because i thought well, itās a haas effect, no need to waste cpu with 2 delays here just so that the transition at 0ms sounds ok. chDelay is a bool that represents if the delay should be applied to channel 0 or 1. itās set in the method where the delay gets its time in ms, because it goes from -20 to 20. negative numbers represent the other channel giving chDelay its value.
iām having a hard time understanding your last paragraph tbh. sry for that, iām still much of a beginner when it comes to programming. i assume that i get a pointer to the 2dimensional array with buffer.getArrayOfWritePointers();. isnāt that supposed to be the memory block of samples that i want to process with my delay? i googled āmemory cache scrubbingā and wikipedia gave me a definition that had something to do with computational errors that only happen once a year due to some weird radiowaves in the air or something. i guess thatās not what you mean hereā¦ or is it?
One thing at a time then.
Your āchDelayā should be an integer, as you canāt guarantee a bool is 0 or 1, it could be 0 and -1 (or anything the compiler wants it to be), but itās certainly is a really bad idea to access an array with a boolean!
You could of course just send the pointers and let the delay handle the stereo, so it can handle things like cross feeding channels for ping-pong delays and the like.
Otherwise, you really do need a delay for each channel like the above code.
If you are using std::vector to store the samples inside delay class then you have to aware of how std::vector works and do the circular buffering logic properly to avoid relocation of vector.
ok, so i just changed chDelay from bool to int and rebuilt the plugin. honestly, iād be surprised if this was the solution because the random clicks in my friendās audio playback donāt come when the delay parameter has changed, but constantly in irregular intervals.
not sure why you call both of these. donāt they point to the same memory address and therefore have the same data, just with the difference that one of them canāt be overwritten?
Iād appreciate it if we stopped talking about having to use 2 delays now. Only using 1 delay here was a decision based on the fact that a haas delay only needs to delay one channelās sample data.
when the sampleRate changes I allocate a little more than enough samples for 20ms. it works on my machine so I suppose the logic is correct.
i guess iām doing that, but you can check if you want to:
wIdx determines where to write in the buffer. ofc it just moves one up for each sample.
data is the vector.
dIdx is the current index of the delay, a value between 0 and whatever amount of samples corresponds to 20ms.
inertia is a variable with some value way below 1 to slow down the movement of dIdx on a parameter value change.
delay is the current delay in samples.
not sure atm why i checked if dIdx goes higher than size, since itās not supposed to be able to do that atmā¦ um but i guess it shouldnāt do anything atm. (iāll try)
rIdx is the index that weāll read a sample from, so it relates to wIdx and dIdx.
then we read and return the sample with no interpolation. (i also tested linear interpolation and spline interpolation but the problem persists)
edit: ok just checked. deleting the check with dIdx and size makes no difference. i guess it was left from another experiment.
edit2: i have a question, maybe itās a little weird butā¦ is it always guaranteed that channel 0 is left and channel 1 is right or do different DAWs interpret that differently?
As a sidenote: bool to any other integral type maps false to 0 and true to 1 -this is guaranteed by the standard. Indexes are size_t, so both int->size_t and bool->size_t are conversions, but theyāre both defined.
The read and write pointer can be different addresses on different DAWs, you canāt presume that itās the same everywhere.
A weird clicking noise might be your friendās buffers sizes. Can you get them to check their audio settings, and possible increase FLās audio buffer sizes? edit BTW you could allocate your buffers in here:
void prepareToPlay (double sampleRate, int maximumExpectedSamplesPerBlock)
Are you 100% of this? Iām not sure how this can be true in JUCE, as the only difference between getReadPointer and getWritePointer is the constness of what the return pointer is pointing at.
Of course I may well have misunderstood something, but it certainly looks to me like the only difference there is setting the isClear member when getting a write pointer, and that the return type is const Type* for a read pointer as opposed to Type* for the write pointer.
if this is the case then my implementation with chDelay being bool should work fine and defined. i changed it to int now anyway and still waiting for my friend to test it. if the problem persists i change it back to bool since that seems to be well defined.
ok iām pretty sure that itās the same address for read and write from looking at these methods. however i use getArrayOfWritePointers(). the documentation for this method says:
Don't modify any of the pointers that are returned,
and bear in mind that these will become invalid if the buffer is resized.
so when i do something like sample[ch][s] to get the sample at channel ch and sample s, i assume iām not āmodifying the pointerā but just reading from its memory address, right? it also says that it becomes invalid if the buffer is resized. but i get a new pointer for each start of processBlock. so can i assume that the buffer wonāt be resized until the end of processBlock or could this be my issue?
i assume by using buffer.getNumSamples() iād always use the amount of samples that is given by the DAW right now, so it should work platform- and buffersize-independent, right? Iāll totally try telling him to change his buffer size and then tell me if it changed anything though. worth a shot.
yeah i noticed that prepareToPlay also gives you the amount of samples per block. but iām not sure how this can be used. i mean imagine i iterated over this āmaximum sizeā and some of the entrys are just empty or full with garbage because the actual buffer is smaller or so. or i misunderstand something about this argument, idk. i just never found a way to utilize it yet.
edit: oh you meant allocating the buffers. yes, already do that. prepareToPlay triggers the resizing of my delay, so that it has a bit more than 20ms of samples.
please keep in mind that the plugin works perfectly fine in my daw. it means that the logic is correct everywhere. it must be a different kind of mistakeā¦ something that makes a difference between his and my computer, or his and my daw.
If chDelay is not getting flipped somehow, inertia is always 0ā¦1, and your delay line is not resized out of prepareToPlay, I can only suspect a performance problem as Dave suggests -at least with the information we have so far.
when the delay in ms parameter is being changed chDelay is flipped to either 0 or 1 and the delay gets the absolute value (0, 20) of the parameter (-20, 20). the delay then transforms this to a buffer length in samples and resizes itself. the delay received the sampleRate from prepareToPlay before. inertia is supposed to be < 1 and itās only meant to slow down delay rate changes. that works fine in both of our daws already, we checked on a test signal in an oscilloscope. about the performance issue: itās just a little haas effect. even if it had the most terrible code ever, it would never max out the cpu so much that the crackles come from that. please consider that i might be pretty much of a programming beginner, but not so terrible that iād reallocate vectors all the time or pass objects that are bigger than double not by reference or something.
EDIT: WAIT! or is it actually possible that fl studio calls prepareToPlay more often than just when the sampleRate changes? because that would really suck atm and it would explain why the crackle comes in irregular intervals.
I just tested FL Studio with one of my plugs - prepareToPlay to be called at least 20 times on boot up! Then again when I click stop twice on the transport bar.
Itās probably best to check for any changes before doing allocations in there.
this actually gives me hope, man this would just explain everything as my vector reallocates with prepareToPlay, because i donāt check if the sampleRate is still the same, since this was never a problem in cubase
I did it and it works perfectly fine in my DAW, cubase artist 9.5.5, but in his DAW, fl studio he gets a lot of weird clicking noises, as if some discontinuity occurs in random intervals. Iām just wondering how stuff like that can happen in general. I mean I didnāt even use any delay implementations of JUCE. I just very traditionally put samples into a vector, while getting samples from another part of the vector (circular buffer), nothing special and especially nothing that should produce different results in different DAWs or even operating systems. (Both of us use windows though, so at least thatās not a problem)