Solving platform-dependent problems

So chDelay is the parameter’s sign and delay its abs value -that seems ok.

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.

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.

In absence of better explanations, better check it first.

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

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.

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 :slight_smile: but also how bad i am :cry: )

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:

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! :slight_smile: i would have never thought of these solutions! or it would have taken forever, idk. big thanks!

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… :slight_smile:
Eg.: 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!!!

1 Like

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

1 Like

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.

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?

I think historically it’s a VST 2 thing when they had processReplacing() & process()
Here:
http://jvstwrapper.sourceforge.net/vst20spec.pdf
Although I seem to recall I’ve seen different pointers in both functions.

2 Likes