@Lindon Yep - totally get what you're saying!

@Christoph-Hart said in Embed non-audio files into the plugin?:

@Orvillain are nam files binary or json?

There‘s currently a gap in all non image or audio file resources (.hwt wavetables too eg), so this would be a good feature addition

Binary files, I was trying to use the AudioFiles folder as a hack, basically.

@Lindon Hmmm, no they are not. Not at the moment. I have embed audio files and embed image files enabled btw.

I have ported over NAM to HISE for my plugin, and I want to embed some NAM files into my plugin. I put them into the AudioFiles directory, and they work and load inside HISE just fine. But they don't load in the compiled plugin. Any thoughts???

@David-Healey Ahh cheers dude. Yeah I get it now. So I've done this for my factory content and it worked fine. I need to figure out expansion packs, but I would guess it is a similar approach; making sure my expansion pack installers put the files in the correct place, and having the plugin scan on startup.

Also, worth remembering... a compiled plugin CANNOT use the builder - at least for the most part. So what I've also got is a PluginStateData namespace, which maintains a key:value dictionary of module id's to module references. This runs on plugin instantiation, retrieves all of the actual object references, and stores them in a const dictionary.

You should only use the builder to build the module tree. You should not use it for retrieving or storing id's or object references.

If in doubt, add the thing manually, and fish the info out of the xml. I've got a tree builder namespace for my plugin, that builds the entire module tree to the spec I've laid out. It is pretty cool and powerful once you get your head around it. But I don't blame you for the confusion; took me a while to understand!

Now... SampleStart .... no... it doesn't seem to exist in the builder from memory. I'm sure I reported this before.

The most confusing thing is getting your head around the chain indexes. I wish the API was a bit nicer for that. It also is very crashy.

namespace BuilderModuleTree
{
    const builder = Synth.createBuilder();

    inline function buildModuleTree()
    {
        builder.clear();
        // Build stuff here - in my plugin, I have other namespaces like BuilderModuleTreeEffects and BuilderModuleTreeSamplers for example.
        builder.flush();
    }
}

I have a system where I have sidecar files next to each of my samplemap xml files. But then I've also turned my samplemaps into monolithic ch1 files. So my metadata (custom things like category, author, studio location, sound source, etc) gets picked up in the HISE standalone dev environment. But not inside the compiled plugin. Still trying to trace down why. But it strikes me that if I can avoid a sidecar file, and just embed the data directly into the sample map and the final ch1 file, then that would be desirable.

Thoughts?

@Christoph-Hart Lovely stuff! Thanks!

@DanH Not yet actually! Potentially another good reason to just build a custom panel.

@Christoph-Hart

		// Walk up to the top-level component to avoid clipping by
		// intermediate parent containers (e.g. panel areas).
		if(auto pp = parent->getParentComponent())
		{
			// Convert drag areas and label from parent-relative to top-level-relative coords
			auto topLevel = parent->getTopLevelComponent();
			auto parentOriginInTop = pp->getLocalPoint(topLevel, juce::Point<int>(0, 0)) * -1;

			dragAreas.offsetAll(parentOriginInTop.x, parentOriginInTop.y);
			
			if(!labelArea.isEmpty())
				labelArea.translate(parentOriginInTop.x, parentOriginInTop.y);

			topLevel->addAndMakeVisible(this, -1);
		}

For my usage, I had to change to the code above.

I think we need the Z-order to be dynamic. But I also think the parenting strategy needs to be dynamic. Either DirectParent, or TopLevel. How easy would that be to add?

DirectParent == current behaviour, where you want a container panel to clip the hover panel.
TopLevel == popup always floats about everything; probably correct for 99% of use cases.

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain There should probably be an option for either. There's also the labels to think about as well... It's not a one size fits all solution.

I just found another issue too - when you have your knobs inside a panel, that panel can easily clip off the floating popup for these depth knobs.... which is kind of annoying. Maybe the best solution for me actually IS to write a custom script panel that knows what knob we are hoving over, and assigns the depth knobs dynamically.

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain because my draggers (depth knobs) are always visible. All of them. So if I switch panels then the draggers still sit on top of the new panel. Make sense?

Yeah that makes sense. I think I might’ve been tempted to handle it a bit more locally rather than adjust the framework, it seems a bit sledgehammery to me, because I think the majority expected behaviour is that these mod depth knobs always sit on top of everything, and disappear when you move the mouse away. But that’s just my instinct. Interested to hear your thinking.

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain any panel that you want to appear at any point, let's say a floating mini preset menu, or a floating tooltip, or a page, the draggers will sit on top of. However mine are persistant, rather than appearing on hover, so that changed the dynamic a lot.

I don't get it. Why are those things related to drawModulationDragger/drawModulationDragBackground ??

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain I found the scenario!!

I'm curious what it was ?

@Christoph-Hart Yes, that fixes it.

I did this:

pp->addAndMakeVisible(this, -1);

But I'm guessing the -1 isn't even necessary.

I'm honestly struggling to think of a scenario where you wouldn't want these depth knobs to always be on top of everything, to be honest!! But... if there is a need to support dynamic z-order assignments, then I'm a +1 to that!

@Christoph-Hart said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain I think that was a custom request from @DanH - he was complaining that the mod draggers mask sibling components so I added some code that give them the same z-level as the knob that spawns it.

Check:

https://github.com/christophhart/HISE/blob/2b3d9bc0b3cb5817dcda1f5bd6366aba123531ab/hi_core/hi_core/MacroControlledComponents.cpp#L1280

If you remove the pIndex+1 parameter, the component is added at the bottom of the list with the highest z-order. Does that fix your problem? Let me know if it does, then I'll check where I can add this property so you can control it dynamically (and ideally per component).

haha, I literally just went digging through the code and found that line. Testing that fix locally. Will report back.

Is there anything I can do about this??

Am I going to have to write a custom script panel that targets all of the mod depths via the mod matrix API ???

When drawing a custom box using drawModulationDragger and drawModulationDragBackground, there is a z-ordering issue with other controls.

Any components that occupy that same screen region will paint on top of the modulation dragger output.

@Christoph-Hart is this a known issue???

I'm running into an issue with 'path' on MacOS. This is with some custom 3rd party C++ code I am using for a node. I get this error:

Error: 'path' is unavailable: introduced in macOS 10.15

So I am guessing that somewhere the minimum Mac deployment target is probably 10.13 or something, and it needs to be set to 10.15. But I cannot see where to do this?

Sorry if this is a n00b question!