# Solving platform-dependent problems **URL:** \ **Category:** General JUCE discussion\ **Created:** [October 2, 2020, 2:59pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015 "2020-10-02T14:59:09Z")\ **Posts on this page:** 9\ **Page:** 2
**Author:** ![kamedin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kamedin/32/11711_2.png) [@kamedin](https://forum.juce.com/u/kamedin)\ **Post date:** [October 4, 2020, 3:13pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/21 "2020-10-04T15:13:55Z")
So chDelay is the parameter’s sign and delay its abs value -that seems ok. > [@hdlAudio](#): > > the delay then transforms this to a buffer length in samples and resizes itself. I don’t quite get this -you mean the delay line’s length? It’s not a good idea to resize the delay line on a parameter change -set it to the max possible delay for the current sampleRate in prepareToPlay. I don’t think this would cause _constant_ problems, but it would certainly cause them on parameter changes. > [@hdlAudio](#): > > is it actually possible that fl studio calls prepareToPlay more often than just when the sampleRate changes? It should be called to reset the plugin for some reason -sample rate changes, channel configuration changes, moving the plugin around, etc. Still, you shouldn’t resize anything if the sample rate hasn’t actually changed. > [@hdlAudio](#): > > about the performance issue: it’s just a little haas effect. In absence of better explanations, better check it first. ---
**Author:** ![Mrugalla](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mrugalla/32/13092_2.png) [@Mrugalla](https://forum.juce.com/u/Mrugalla)\ **Post date:** [October 4, 2020, 3:21pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/22 "2020-10-04T15:21:40Z")
> [@kamedin](#): > > It’s not a good idea to resize the delay line on a parameter change you’re right. for some reason i used the wrong terms here. the buffer does not resize, sryy. it’s just the delay-variable that changes. the one that is used in dIdx += inertia \* (delay - dIdx) * * * ok now something weird happened! my friend checked the first build i made today, the one with the bools being int. and then it apparently worked perfectly. sooo it seems this really was undefined behaviour. i hope he wasn’t just lucky and the problem is still there. now we can’t check if the 2nd build with the sampleRate being checked for changing also makes a difference since it already works now, but i’ll still check for it in the future to prevent uncertain things from happening ---
**Author:** ![kamedin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kamedin/32/11711_2.png) [@kamedin](https://forum.juce.com/u/kamedin)\ **Post date:** [October 4, 2020, 3:29pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/23 "2020-10-04T15:29:54Z")
> [@hdlAudio](#): > > it seems this really was undefined behaviour. But it’s not. 7.3.8.2: “If the source type is bool, the value false is converted to zero and the value true is converted to one.” Something else must have happened. ---
**Author:** ![Mrugalla](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mrugalla/32/13092_2.png) [@Mrugalla](https://forum.juce.com/u/Mrugalla)\ **Post date:** [October 4, 2020, 3:31pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/24 "2020-10-04T15:31:17Z")
ok let’s sum this up: my problem was that due to only ever using cubase i assumed things to work without checking for it, but it was actually undefined behaviour and cubase just implements it the way i expected it to work. (shows how good cubase is 🙂 but also how bad i am 😢 ) things i learned: - can’t expect bool to represent 0 and 1. (or can i, maybe. maybe not) - can’t expect prepareToPlay to be called rarely. edit: > [@kamedin](#): > > Something else must have happened. if this is true then it must remain a mistery for now since the plugin works and i really didn’t change anything else about it lately. idk… sry about that. i wish i could be more certain about everything, too. edit: oh yeah, thanks everyone! 🙂 i would have never thought of these solutions! or it would have taken forever, idk. big thanks! ---
**Author:** ![DaveH](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daveh/32/4924_2.png) [@DaveH](https://forum.juce.com/u/DaveH)\ **Post date:** [October 4, 2020, 3:53pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/25 "2020-10-04T15:53:36Z")
Try getting as many DAWs as you can, there are quite a few demo versions out there. Testing on as many systems as possible will become more normal as time goes on… 🙂 Eg.: [https://www.image-line.com/fl-studio-download/](https://www.image-line.com/fl-studio-download/) Perhaps your friend already adjusted FL’s buffer sizes, without thinking about it. Don’t presume anything, Juce helps quite a lot, but you still can’t presume anything!!! ---
**Author:** ![Mrugalla](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mrugalla/32/13092_2.png) [@Mrugalla](https://forum.juce.com/u/Mrugalla)\ **Post date:** [October 4, 2020, 4:13pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/26 "2020-10-04T16:13:18Z")
yeah my friend is quite a chaotic mind, just like me. it could really be anything that has solved this issue now. but i think i still learned something here because this just showed that you can not always be sure that a method works the same everywhere, even if its logic might imply a certain usecase ---
**Author:** ![DaveH](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daveh/32/4924_2.png) [@DaveH](https://forum.juce.com/u/DaveH)\ **Post date:** [October 4, 2020, 4:28pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/27 "2020-10-04T16:28:42Z")
Lol, yeah. BTW the reason I brought up the read and write pointer thing, was that before I used Juce, either the AU or the VST used to give me different pointers. I don’t know how Juce juggles the buffers internally (hopefully not too much). I’m just trying to future-proof my code as much as possible. ---
**Author:** ![Mrugalla](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mrugalla/32/13092_2.png) [@Mrugalla](https://forum.juce.com/u/Mrugalla)\ **Post date:** [October 4, 2020, 4:38pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/28 "2020-10-04T16:38:07Z")
i mean, on the one hand it’s totally reasonable to be unsure about things, as we can see in this whole post. but on the other hand: why would 1 audio stream have multiple different buffers depending on wether or not you only want to read from or also write to it? ---
**Author:** ![DaveH](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daveh/32/4924_2.png) [@DaveH](https://forum.juce.com/u/DaveH)\ **Post date:** [October 4, 2020, 4:49pm UTC](https://forum.juce.com/t/solving-platform-dependent-problems/42015/29 "2020-10-04T16:49:55Z")
I think historically it’s a VST 2 thing when they had processReplacing() & process() Here: [http://jvstwrapper.sourceforge.net/vst20spec.pdf](http://jvstwrapper.sourceforge.net/vst20spec.pdf) Although I seem to recall I’ve seen different pointers in both functions. [Previous page](https://forum.juce.com/t/solving-platform-dependent-problems/42015.md?page=1)