Ok... I've obviously have not had enough coffee today. I'd probably have to export the plugin after I rebuild HISE for something to take effect.
Ignore my stupidity for now.

It appears to be something with the exported plugin. The machine IDs generated with JUCE_USE_BETTER_MACHINE_IDS=1 are the same as if it's set to false. At least I know where to start looking

@ustk I've changed the preprocessor in the module like this:

Still the same result

I'm not sure what I'm doing wrong here, but HISE and my compiled plugin can't agree on a "better" machine ID.

I've compiled HISE like this:

and added this to my project:

When I launch the plugin, it detects that the ID is different and I update my license file. Then when I load HISE, it still thinks that the ID is different. What am I doing wrong?

@Christoph-Hart

@Christoph-Hart January 1st or 2nd?

@clevername27 Unfortunately, I endure the same amount of suffering as everyone else.

@CyberGen What about calling the change after a delay?

Content.callAfterDelay(500, function(){
     Knob1.setValue(1);
     Knob1.changed();
}, this);

@clevername27 This happens randomly to me as well. It's possible that a script it taking loner to load than anticipated and the app chokes. I just hit recompile a few times and it usually comes back to life.

@trillbilly said in VirtualBox + Export Wizard:

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

See if this helps:
https://stackoverflow.com/questions/17980759/xcode-select-active-developer-directory-error/17980786#17980786

@Christoph-Hart Any chance we can get this on your radar? Webp is the preferred image format for websites these days. It would be very helpful to be able to render them in HISE. I believe support was added in JUCE7?

There are some helpful notes in the source code:

        /* REGARDING THE MAX PEAK: This method assumes that the only important
         * sample in a look-ahead buffer would be the highest peak. As such,
         * instead of storing all samples in a look-ahead buffer, it only stores
         * the max peak, and compares all incoming samples to that one.
         * The max peak has a hold time equal to what the look-ahead buffer
         * would have been, which is tracked by a timer (counter). When this
         * timer expires, the sample would have exited from the buffer. Therefore,
         * a new sample must be assigned to the max peak. We assume that the next
         * highest sample in our theoretical buffer is the current input sample.
         * In reality, we know this is probably NOT the case, and that there has
         * been another sample, slightly lower than the one before it, that has
         * passed the input. If we do not account for this possibility, our gain
         * reduction could be insufficient, resulting in an "over" at the output.
         * To remedy this, we simply apply a suitably long release stage in the
         * envelope follower.
         */


        /* REGARDING THE ATTACK: This limiter achieves "look-ahead" detection
         * by allowing the envelope follower to attack the max peak, which is
         * held for the duration of the attack phase -- unless a new, higher
         * peak is detected. The output signal is buffered so that the gain
         * reduction is applied in advance of the "offending" sample.
         */

         /* NOTE: a DC offset is not necessary for the envelope follower,
          * as neither the max peak nor envelope should fall below the
          * threshold (which is assumed to be around 1.0 linear).
          */


        /* REGARDING THE GAIN REDUCTION: Due to the logarithmic nature
         * of the attack phase, the sidechain will never achieve "full"
         * attack. (Actually, it is only guaranteed to achieve 99% of
         * the input value over the given time constant.) As such, the
         * limiter cannot achieve "brick-wall" limiting. There are 2
         * workarounds:
         *
         * 1) Set the threshold slightly lower than the desired threshold.
         *        i.e. 0.0dB -> -0.1dB or even -0.5dB
         *
         * 2) Clip the output at the threshold, as such:
         *
         *        if ( in1 > thresh_ )        in1 = thresh_;
         *        else if ( in1 < -thresh_ )    in1 = -thresh_;
         *
         *        if ( in2 > thresh_ )        in2 = thresh_;
         *        else if ( in2 < -thresh_ )    in2 = -thresh_;
         *
         *        (... or replace with your favorite branchless clipper ...)
         */
    }

I’ve come across the same results as you. Using the AIDA-X pipeline as my starting point as well. It’s a challenge to get consistent results, especially with sources that contain a lot of harmonics.
I’ve been tweaking the training scripts to get a more usable result but don't have much to report yet.

I experience the same. Haven't had a chance to look into it, but I think @Christoph-Hart would know what to do.

@orange ahh... lemme take a look at the snip

Something like this:

if(input >= 0){
//apply positive processing
}

else{
//apply negative processing
}

This is how you get all the project info:

Console.print(trace(Engine.getProjectInfo()));

@d-healey
If generating dynamically, use String.fromCharCode with parseInt.

Is there an equivalent in HISE?

From the web:

\u is used in JavaScript and similar languages for Unicode escape sequences, but it must be followed immediately by a valid four-digit hexadecimal code (e.g., \u1234).

@tomekslesicki same is happening here. Looks like there's an incompatibility with the latest CUDA driver. I'll have to tweak that