Posts made by Cyberdyne387

@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.

@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.

Hello. I know it's been a while...

Been revisiting HISE a little bit again. That said, one thing that's stumped me even back when I used HISE last: I cannot drag and drop samples into the Audio Loop Player in release builds of HISE, including with unmodified source code. Some tweaking of my XCode projects helped me discover that it may be correlated to the link-time optimization, as disabling that setting in XCode fixes the problem. Still, I think it's something that should be looked into, for people who like to drag and drop sounds.

@Christoph-Hart said in Sampler issues latest build:

FYI, that's the code that handles samplerates:

if (isOldMonolith)
{
    return 44100.0; // doesn't matter anyway (the sample rate is stored externally)
}
else
{
    const static double sampleRates[4] = { 44100.0, 48000.0, 88200.0, 96000.0 };
    const uint8 srIndex = (sampleDataByte & 0xC0) >> 6;
    return sampleRates[srIndex];
}

Now it also makes sense why @staiff is struggling with his 27,4kHz sounds :)

Thanks for this notice. I too have needed to repitch my own samples after compression due to unusual sample rates (frequent ones for me being 32 and 50 kHz).

Sorry for my frequent silence, first of all. It seems my commitment to distributing my own HISE project keeps phasing in and out.

That in mind, when it comes to the original subject, I was able to heavily edit the source code so that you could specify a different sample in a sample map via scripting. I don’t recommend this, as even if it had Christoph’s input, I’ve had occasional loading errors in the past, particularly over looping and whatnot, but it is a way to make use of user multisampling, for instance.

Just tested your version of the edits for myself, only to need to revert back to my version of StreamingSamplerSound. Both copies of the file work fine when there's no sample start offset, but it appears the one you committed causes the loop to play silence for the duration of the sample start offset

@christoph-hart Not a problem when it comes to testing the code extensively before committing. I did realize I made a minor mistake in my fix, anyway: the force-reloading of the preload buffer I had only run when the looping is set to enabled, meaning it will play the duration of the sample as a loop even if the last loop change you did was disabling the loop. Fixed on my end now, with the same link.

@macromachines

First of all, apologies for taking so long to read this: truth be told, I’ve been pretty swamped with other matters.

It’s important to note that I may not have the modified code in its entirety anymore due to trying to keep my HISE source code updated every so often, and even if I do, I never did find a C++ way to address the sample-end-too-short issue. I’m willing to share my edit for the loop-end-too-early issue, however, and I may still have a JavaScript that adjusted the preload size so that the loop would play at all regardless.

UPDATE: found the fixed C++ file. It should hopefully compile fine with the latest source code.

https://www.dropbox.com/s/ksj4v2mctlm183a/StreamingSamplerSound.cpp?dl=0

To specify what exactly I changed when it comes to this issue, Christoph wrote a conditional statement in the setPreloadSize function for the circumstance of if the entire length of the sample is too short for the internalPreloadSize, but looping is enabled. What I changed is I added an additional conditional statement checking to see if the loop end point is also smaller than the internalPreloadSize.

As for whether the loop plays at all under a given preloadSize, sadly, loops and loading the entire sample seem to not get along well at this time, so my final change was specifying that entireSampleLoaded be false if the preloadSize is larger than the loop end point. In addition, I also specified the loopChanged function to force-reload the preload buffer in the high chance that you wish to change the loop but not the preload buffer size at a given time.

Hopefully this helps people out.

Another technical question.

To build background, one reason why I decided to resume my HISE project is because of the JUCE team announcing that version 5 of their tools are free to use and even sell closed source code with (within income limits) for everyone.

That being said, do you have plans to make HISE compatible officially with JUCE 5? As a free JUCE user, the current workaround I found was to edit the provided JUCE 4.3 code to include the splash screen mandatory for Personal (free) licenses, and I still haven't confirmed if I got the also-mandatory analytics working with HISE yet.

Hello,

As Christoph knows, I've been working with HISE with modified source code. That being said, I did take note of the fact that the vanilla version of HISE had two issues with preloaded samples. The first issue is that if a loop endpoint is defined to be a value smaller than the preload size, the sample won't play the loop properly until after it has read the preload buffer. I did make a fix for that via my source code edits, but still something worth addressing for the other users.

The other issue I encountered is that if the preload buffer is at least the same size as the sample (whether it is explicitly supposed to preload the entire sample or not), it will not loop at all. Was this lack of loop support intentional? Either way, the best workaround I've found for this for my own purposes is to make the preload buffer decrease its size if the sample size is under a certain number, in my case, 8192 samples.

Thank you for your time.

Thanks for the notice about not hearing any complaints from High Sierra users yet. I guess I'll chance it when enough of my other software becomes compatible (I know for a fact Native Instruments products are not at this time).

Interesting bug you experienced when upgrading to Sierra, though.