@d-healey it's my understanding that logic and pro tools support mono to stereo where a mono track becomes a stereo track at the insert point where the user inserts an m>s plugin.

this plugin does not make sense to run as mono > mono.

Yes to both. There is a lot. I'm currently going through the process of commenting things out and making test versions to see if I can make one that works.

@d-healey Yes. I do have a high dpi mouse and now you’ve given me something else to worry about and have to test for. I did not think that dpi could be a factor.

Based on what I figured out rooting around the Hise source it seems like all sliders in Hise are set to absolute px mode as default with a value of 250 distance = full rotation. But when you turn on the modifier they switch to a velocity mode. The problem I had is that the velocity mode settings weren’t any good (at least for my mouse) specifically the offset aka minimum.

https://docs.juce.com/master/classSlider.html#a47c37989ff5f6453f2c44f1a7455e1c1

I found a setting that makes things much smoother and more predictable. But I guess I have to test with different mice?? Oh joy.

Where can I change the compile options that Hise uses when compiling faust nodes?

I can open the .cpp file generated by Hise for my faust dsp and it has the compile options Hise used commented out at the top, but I don't know where in Hise I can edit those.

As an example I would like to use double precision floats. Hise is currently set to use single.

@aaronventure thanks!

I had actually just figured out on my own how to do this with a gain module directly. But your version in scriptnode is better.

@Christoph-Hart thanks for tackling this issue so quickly!

Tested as working on my end.

@d-healey said in [Feature request] Missing Laf colour properties:

• drawPopupMenuBackground, use the combo box colour properties (would also be good if the base colour was transparent so we could do rounded corners, currently it's solid white).

This please!

Haha dirty indeed. But it works!

I don't know why but the mouseDownX and mouseDownY values I get when clicking on the panel are always huge. So I'm using an X that's higher than my object width to trigger that? Idk man... haha

if (event.mouseDownX > 26) {
	//click on panel
	//first click shows menu, second hides menu
}

if (!event.hover && !event.mouseDownX) {
	//click off of panel that also hides menu
}

2025 Bump

Is this still missing functionality? I know there is a clear undo list function, but there doesn't seem to be any way of knowing if you're at the beginning or end of the undo list or how many items are in it.

So until we have native Cmajor support in HISE, how much of a pain would it be to compile a Cmajor patch as C++ and then use it in HISE as a 3rd party C++ node? Is there a web of dependent libraries you'll have to worry about including?

@d-healey Yah I'm assuming that must be the case. I'm going to try a fresh pull and build.

@d-healey Following that option in the file menu brings me to a new different location. It now makes a folder when I hit that. But the folder is empty. It's not saving any config files inside it.

@d-healey You mean the settings folder that on Mac is in application support, right? I already thought about that and tried it.

I renamed the old folder and HISE didn't create a new one. Settings still not saved.

Trying out the latest dev commit which I built last night and running into an odd situation. I'm on MacOS.

Hise seems to never save any gear menu settings.

I open a project, hit the settings gear button, Hise path is blank, I point it to the proper path, hit save, save my project, close HISE. Reopen, check the settings gear... and path is blank again. Other things also seem to reset to a default every time.

If I load my old HISE build it still functions fine.

How well does this nam implementation handle different sample rates? I know some get tripped up if you try to run a sample rate that's different than what your model was trained on.

Just wanted to voice my support for having this in HISE.

So until we have native Cmajor support in HISE, how much of a pain would it be to compile a Cmajor patch as C++ and then use it in HISE as a 3rd party C++ node? Is there a web of dependent libraries you'll have to worry about including?

@obolig maybe accidentally compiling for debugging instead of release?

I wrote a reply but I guess it got sucked into the void with the forum server instability yesterday.

I did get it working. The things I changed were that I switched to using a global_cable node instead of a global_send. I don't understand why I needed one over the other but with that change my scriptnode now compiles fine.

Also I needed to be routing a 0-1 value to the cable input in scriptnode. I was sending a negative value which shows up fine on the value knob readout in the scriptnode but I guess was being clamped to the 0-1 range and showing up as all 0.0 once it was read by the interface script. Using the .setrange() function apparently maps 0-1 data being input to the range you set, it doesn't change the requirement for the input data to be within 0-1.

All of this is somewhat stabs in the dark as there seems to be very little documentation on anything scriptnode. But it is working.

@oskarsh that sounded like a good idea and something I obviously missed, however after that fix I'm still getting 0.0 values returned.