@d-healey That's the other reason why I bring this up: I don't know for certain. My guess is it won't affect other platforms since the only difference is that I explicitly specify which Point class the code is referring to, which, evidently, was JUCE's anyway.

@d-healey Sorry I didn't make it clear with the background of this bug: my most recent tests have been with the source code that was available yesterday.

I appreciate the suggestion of combining separate modulators. Thankfully, I've just found a method that makes use of the apparent fact that the modulation amount can be scripted to have a value greater than one, so the problem is solved. :)

@d-healey That's the other reason why I bring this up: I don't know for certain. My guess is it won't affect other platforms since the only difference is that I explicitly specify which Point class the code is referring to, which, evidently, was JUCE's anyway.

@d-healey said in Building for Catalina:

@Cyberdyne387 I see, I think others have got around the problem by using an older version of XCode.

Well, again, I did make it work on my end with the current version of XCode by specifying what classes for Points instead of leaving them ambiguous. I just brought this up to see if Christoph is willing to update the code to address this.

@d-healey said in Building for Catalina:

@Cyberdyne387

macOS Catalina SDK

What's that for? XCode?

Exactly.

@dustbro Having looked at this whole message now, that’s good to know there’s an automated way to update the class names in the cpp files. Will make use of that next time I try building.

First of all, apologies for my delayed response.

d.healey is correct about one thing: I don't have any JUCE 6 installations on this particular computer. When I said the SDK, I was referring to the macOS Catalina SDK, and I know it's a problem with that because using an older SDK (i.e. for Mojave) circumvents this problem.

Also, just to clarify: the latest version I have of Projucer is 5.4.7, and I didn't even use that for my current build.

Hello again,

So after some time, I revisited Hise by way of updating the source code I had of the project. That said, I feel it best to let everyone involved know: if you want to build for macOS Catalina using its own SDK, in addition to specifying 64-bit only builds, you also have to change all of the references to "Point" in the source code to specify "juce::Point". If my hunch is right and that is the correct type being referenced, then am I correct in assuming that fixing all of the code for everyone wouldn't effect non-Mac users? If so, then I feel it's worth addressing.

Thank you for your time.

I appreciate the suggestion of combining separate modulators. Thankfully, I've just found a method that makes use of the apparent fact that the modulation amount can be scripted to have a value greater than one, so the problem is solved. :)

@Christoph-Hart Thank you for getting back to me, first of all. Yes, I did see in your git history that you intentionally removed its functions since I wrote the OP.

This particular envelope was actually intended to be a modulator for my filter in two ways: the cutoff itself (assuming the unmodulated cutoff is set to the maximum frequency), and its ability to keytrack. If the TimeVariant equivalent supported polyphony, then I would've gone for that route, but here we are.

Can this be done with ScriptNode? If so, how do I go about "converting" my script?

Sorry to spam with another message, but now I have a discrepency with the documentation. I've been using a custom-scripted envelope, and it appears that the newest ScriptNode source code breaks it. Upon looking into the module, I see that there are now only two scriptable functions: "onInit" and "onControl". Does this mean I need to rewrite my envelope completely? Or is this a bug?

@Lindon Ah. I downloaded from the default branch for me, which appears to be the "master" one.