Just wondering if distributing FLAC 24bit 44.1k or 48k is preferable?

The sounds are short plucks (from hardware synth) and percussion short hits. Normalized to -3db.

I think -73db noise floor is OK. The sounds won’t be stacked really, so the noise floor won’t pile up.

More info at GForce Software

Speak soon!

However no matter how I set it up there are issues. Either the buttons don’t display the correct value or the AudioProcessorValueTreeState parameter doesn’t follow up, or the buttons don’t stay down after I clicked, etc.

More than fixing my code, i’d like to see a complete demonstration or example of how to set up radio buttons for a single parameter so I can decline and adapt it to the situations I could get myself into.

If anyone knows how to set that up, please show me. Otherwise I might be back in a few days if I figure it out myself.

Components with a lot of graphical details use local hit detection to determine the anticipated drop action. For example, you probably don’t want to create a nested juce::Component for every note head on a staff in a notation app. The notation component will rather look for the note under the mouse and respond to isInterestedInDragSource() accordingly (e.g. expecting to drop a color swatch on the note head).

Fortunately the fix is trivial:

juce_DragAndDropContainer.cpp, line 314, ff

    while (hit != nullptr)
    {
        if (auto* ddt = dynamic_cast<DragAndDropTarget*> (hit))
        {
            auto p = hit->getLocalPoint (nullptr, screenPos);
            details.localPosition = p;
            if (ddt->isInterestedInDragSource (details))
                return std::tuple (ddt, hit, p);
        }
        hit = hit->getParentComponent();
    }

The function findTarget() operates on a copy of SourceDetails anyway, so setting localPosition immediately before calling isInterestedInDragSource() does the trick.

Please consider this fix for integration. Thank you.

See WebView2 Win32 C++ ICoreWebView2CompositionController | Microsoft Learn

Since we now use the D2D renderer which participates in the modern windows visual tree (see JUCE/modules/juce_gui_basics/native/juce_Direct2DHwndContext_windows.cpp at 501c07674e1ad693085a7e7c398f205c2677f5da · juce-framework/JUCE · GitHub ) it feels like it should be possible to create and insert another visual here that I can bind to the WebView2 Composition Controller.

Will this be made available in the future as an API, or is there a recommended path for forking my own way to get this capability?

Thanks for your reply.

I’m seeing the same behaviour in Safari as well. However, Firefox seems to handle it fine.

For me it does occur regardless of which resize handle is used, but it does seem more pronounced when resizing from the top or left edges.

When resizing:

• If the browser content overflows on an axis, resizing appears smooth.
• If the content has overflow: hidden on an axis, a white gap appears during resize.

For example:

• If overflow is hidden on the X axis, a white gap appears on the right edge of the browser while resizing.
• If overflow is hidden on the Y axis, the gap appears at the bottom edge.

To rule out background issues I tried:

• Painting the JUCE component background black
• Using withBackgroundColour() via withWinWebView2Options

However, the exposed area still appears white, so I’m not sure where the white background is coming from.

For comparison, this behaviour does not occur in Firefox or other browsers, where resizing the same content remains smooth without exposing a background gap.

I’ve tested this with JUCE 8.0.12 and the latest develop branch, and both exhibit the same behaviour.

I’ll attach an MP4 demonstrating the issue.

Has anyone else experienced this, or found any workarounds?

33 MB isn’t such a big deal, although DAWs might store the project’s plug-in state as base64-encoded binary data in an XML file, for example, which makes it more like 50 MB.

If the user has recorded less than 6 minutes, it will be worth storing only the actual data they recorded, not the whole buffer. This will make the project file smaller and saving faster.

A DAW such as REAPER will ask the plug-in to save itself every time the user changes a parameter, so ideally you want this to be fast enough to be unnoticeable.

The alternative is to store the recorded sound inside a file somewhere, but this would be outside of the DAW’s project file and the user will have to manage these files manually. You could make a folder named after your plug-in and store the recordings inside that folder. However, if the user moves the DAW project to a different computer, they would also have to copy the folder with these recordings.

(It would be nice if plug-in APIs could tell the host that a plug-in wants to store a file as part of the project, but that doesn’t exist, AFAIK.)

The trick I mentioned doesn’t work with log scaling. But for that it may be a good solution to pre-warp the spectral data before turning it into an image.

<key>AudioComponents</key>
	<array>
		<dict>
			<key>version</key>
			<integer>132776192</integer>
		</dict>
	</array>

I don’t have a version number that is consistently causing rescans. We are not able to reproduce the issue, but a few users on older systems reported that Logic needs to rescan each time. So I thought it might be related to that version number failing when getting parsed. I can’t think of anything else, any ideas? Our plugins pass auval fine, they also pass the Logic scan fine, but for some reason they get rescanned on each run…

I had this issue a long time ago trying to make it act like Ableton style keypress to midi notes . I never resolved it, but it definitely does work with native windows . Maybe try to wrap just that portion that displays the plugins in native windows for each platform .

You should definitely disable that when it’s loaded in a daw as the keystrokes may collide .

Keep it in the plugin memory the entire time until they are ready to commit then restore the buffer from the preset.

I would think with each session you would end up taking up a lot disk space unless they were temporary files, but temp files I assume will get deleted at some point by the OS.

jonagon:

Is it true that you shouldn’t access an atomic in the audio thread?

A variable marked as atomic does not guarantee it’s lock-free, so I can understand why people say something like that. But it only happens in some rare situations, such as unaligned memory from a packed struct, or a large struct marked as atomic, not primitive variables. You can see the notes I wrote here: https://mu.krj.st/ctrl/#atomic-variables

In those cases, libatomic implements the access using a mutex, which is not real-time safe. It’s recommended to check atomic_is_lock_free.

I’m working on a plugin similar to a live looper pedal. It records incoming audio samples in a single std::vector<float>.The vector has a fixed maximum size that is defined at initialization, about enough for 6 minutes of audio at 48 kHz.

The audio data is never stored on disk, so any recording is lost when the plugin session ends. Now I want to make sure that the recorded audio is stored on disk so that the sample memory persists between DAW sessions.

I can expand on the details and access patterns used with the samples vector if it helps. I didn’t want to bloat this post with too much information up front.

I’m wondering how an experienced JUCE developer would approach persisting this kind of audio data between DAW sessions. I am fairly new to plugin development so I don’t have an intuition for what is a good or bad approach. Any advice you can provide would be greatly appreciated.

hugoderwolf:

You could just render the colormap to a juce::Image in memory (at one pixel per time-frequency bin, and of course it makes sense to cache the already colormapped frames) and then draw it with a transform, which will then interpolate (gets you the gradients for free basically). But you should check on your target platforms whether it behaves as expected. The actual interpolation will be done (I think) by CoreGraphics / Direct2D and thus pretty fast. But I guess it might even be more efficient than drawing hundreds of gradients even with a software renderer.

Sure. I will try several approaches to see which is more reliable or consumes less CPU. I will definitely use a juce::Image in cache. One pixel per bin + Transformation seems to be a good idea, but it might not work well for log-scale freq axis? Technically I can also reduce the number of gradients using some explicit interpolation/smoothing methods. I will report it back if I get a practical implementation.

And thanks for the suggestions regarding Pro Tools. Somehow I messed up Pro Tools installation on my M chip MacBook I should definitely contact the customer service sooner.

Plan some extra time to test this on ProTools (macOS). It does some weird things that I’ve seen no other hosts do.

YMMV, I used this trick to some extent and it works well enough for those cases, but I haven’t fully investigated the ins and outs of this approach.

I know how to transfer the data from the audio thread to a background and how to forward the FFT. The problem is how to choose a proper way to reduce the pressure of the message thread:

• should I draw each horizontal line as hundreds of rectangles or as a whole gradient?
• should I cache the image and only updates the new line?

In general, I would assume a structure like this:

void background_thread_run() {
    fft.forward();
    lock_scope(mutex);
    // update some drawing things, like images/gradients/rectangle lists
}

void paint(juce::Graphics &g) {
    try_lock_scope(mutex);
    // if try lock succeeds, actual draw here
}

I notice that drowaudio/module/dRowAudio/gui/dRowAudio_Sonogram.cpp at 1d6e9efe1bd2edaeff8917b15424083bf652ec46 · drowaudio/drowaudio · GitHub uses the cached image + rectangles way. There are also some discussions here: Best method for sonogram display? .

I’m experiencing an issue with KeyCommands on iOS. When an AUv3 plugin is instantiated in my host, the application seems to lose keyboard focus, causing the key commands to stop working. They only start working again after I tap somewhere on the screen.

I tested with the latest Audio Plugin Host (develop branch) to see if the issue was related to how I manage them but I discovered it happens there too.

Could you please run some tests to investigate the cause of this issue?
If you need anything from my side, please don’t hesitate to ask.

I look forward to your response.
Best,
Samuele

A -73 dB noise floor corresponds to a sampling bit depth of about 12 bits, which isn’t uncommon for older gear.

I don’t know about the -3 dB noise reduction. If this is for a synth, it probably won’t sit at full volume in the mix anyway.

I’m looking for an experienced JUCE / C++ developer to help build an MVP of a VST3 plugin focused on real-time collaboration between DAWs.

Requirements:

• Strong C++

• Experience building VST3 plugins with JUCE

• Understanding of real-time audio constraints

• Experience with networking (low latency preferred)

• Mac + Windows build support

This is a based paid contract engagement with potential for long-term involvement.

Thanks,
Gideon

When I was seeing that, it was a white square in the middle of the component while the message queue was getting choked up during initialisation. You seem to be getting a similar artefact in one component, but partially masked by another one which draws over it. But then there are some other flickers as well…

After a lot of experimenting with synth volume, and Sample Robot, I’m getting my samples in at 192k 24 bit. And I plan to convert them down to 44.1khz FLAC (or 48k..not sure yet)

Anyway, this noise floor question is one I’ve been wrestling with. My synth sample I am high passing at 48hz, and low passing at 18khz.

I am normalizing to -3dB, and then LP HP, and my noise floor is -73dB. Is this acceptable? I took a profile of the noise in Izotope RX (7 Standard) and if I apply a -3dB noise reduction my noise floor is -80dB. Trouble is, I don’t want to take any good frequencies out of my sample body, so might not bother with the spectral noise reduction.

Just wondering what you thought of my workflow (my target 44.1 or 48 bitrate(??), normalizing to -3db, and noise floor etc.)?

My plugin won’t stack sounds, its more like a mono arp kind of thing.

Refx2 IMG 1208

Refx3 IMG 1207

Nobody here is interested in solving AI-related problems. You let a plagiarism machine generate garbage and then wonder how to improve the output to be less garbage.

At that point, it’s too late.

I’m not trying to automate mastering or improve mixes in a general sense. The question I’m exploring is narrower: whether small perceptual improvements can be made on a finished stereo render using lightweight DSP (e.g., dynamic spectral shaping) to reduce upper-band harshness or fatigue in AI-generated material when stems aren’t available.

So the interest is really about the limits of post-render DSP, rather than mastering automation.

        /** The time actually provided by the host. May be negative, as opposed to timeInSamples */
        info.actualTimeInSamples = processContext.projectTimeSamples;

Have you got a version number that is consistently causing rescans? it should be repeatable for everybody. If so, is 2026.1 an example of a version causing this issue? Maybe it requires a specific Logic or auval version (in which case maybe logic or the auval version installed are at fault?)

I assume 2026.1 comes out as 0x07EA0100? I think it should be split like so

0xAAAABBCC where

• A represents the Major version (in this case 2026), converted to hex (0x07EA)
• B represents the Minor version (in this case 1), converted to hex (0x01)
• C represents the Patch version (in this case 0), converted to hex (0x00)

This does mean there are limits to the numbers but 2026.1 should be fine, and even if it wasn’t I would have hoped that any change in the version number would only result in the plugin being scanned once?

Something in the back of my mind is telling me that I recall some issue in which going to a lower version caused an issue. However, IIRC the issue was that the plugin wasn’t being scanned rather than it was continuously being scanned, and this would have been a long time ago!

The thing I reported about a version number of 0 was something Apple told me about. The idea is that you can set the version number to 0 during development (or for debug builds) and then your plugin should always be scanned.

I can’t think of anything else that would cause it to continuously scan.

Our versions are formatted like this: year.version (for example 2026.1). This is getting quite a large number when converted to a hex integer - could this be the cause?

Makes sense! Since you are pulling elapsed * sample_rate samples from processor FIFO every editor timer fire, are you using an atomic index pointing to the end of the most recently written FIFO data that updates every block

No, I use an abstract FIFO, similar to juce::AbstractFifo to wrap the buffer. As far as I know you need at least two atomics for an abstract FIFO. Only in such way I can pull arbitrary number of samples from the FIFO, in a safe way.

A few months ago I asked about improving listening comfort in AI-generated music using post-render DSP. Since then I’ve narrowed the scope considerably.

The question is no longer about “fixing” vocals or source separation. I’m only interested in whether a small perceptual improvement band exists when working strictly on a finished stereo mix.

Constraints:

Input: rendered stereo track with embedded vocals

No stems available

No source separation or ML reconstruction

Processing must be lightweight deterministic DSP

No structural remixing or editing

The observation prompting the question is that many AI-generated tracks exhibit upper-band vocal harshness / spectral edge that creates listening fatigue even when the musical content is otherwise acceptable.

Core question:

When operating only on the final stereo signal, is there a meaningful perceptual improvement band where constrained DSP (e.g. dynamic spectral shaping, de-harshing, masking-aware processing) can reduce perceived harshness or fatigue without introducing obvious artefacts?

I’m not expecting a universal solution—just curious whether developers working on audio effects have encountered similar limits or techniques when dealing with mixed stereo material.

Interested in any thoughts from people who build or work on perceptual audio processors.

Though I tested it in Reaper, Ableton Live and FL Studio on Windows and none of them does this.