@lalalandsynth Damn, sorry :)

@ospfeigrp I think we're all using AI to assist in plugin creation.

@blush It's listed under the PathTypes section here: https://docs.hise.dev/ui-components/floating-tiles/plugin/draggablefilterpanel.html

https://docs.hise.dev/images/custom/filterpathtypes.png

@lalalandsynth It depends on the specifics of what you're doing. If you already have a paint routine or look and feel for the component then it's probably better to include the value/label in that rather than add another component to the UI. But if you're using filmstrips a label might be easier - although you probably still have to add scripting anyway.

I also added a LineSpacing and LetterSpacing to the Markdown renderer so I can style it to match my plugin.

https://github.com/christophhart/HISE/pull/1008

Had Claude fix this bug and also added an optional scaling parameter to the screenshot function: https://github.com/christophhart/HISE/pull/1004

I found when unloading a Full Instrument Expansion the automation xml was getting wiped. Made a little PR to fix it.

@David-Healey I was looking for a simple one-man-band way to get past the windows "smart screen" - but thanks anyway....

@Christoph-Hart That is just way too convenient ! 😲

@gonzalo Welcome, !

@lalalandsynth ahh yup. 👍

Update: Claude-generated gist here of the suggested patch: https://gist.github.com/weavermedia/3fc4a419920fcda8de389a89d7aec68d

This is Claude's minimal fix: https://github.com/christophhart/HISE/pull/1003

I've tested it and it appears to work. The fix just closes each file reader after reading the data into the preload buffer.

You're trying to build the Faust build without having installed Faust. Select another Scheme to build that doesn't include Faust (or use the hise-cli for setting this all up).

@ustk Just the ever-tightening security of OS vendors. Privacy is a selling point now, as is anti-machine-fingerprinting.

A user account authentication system, via the browser, feels much more lightweight, predictable and more transparent to the user.

Now that I've reverted to using the hr1 system I ran into this issue again.

I have a library that is going to be about 20GB compressed and when I send out an update to my users that changes only the data (hxi) I don't want them to have to redownload the entire 20GB all over again.

So I worked with Claude to implement a split archive solution.

The default behaviour is the current behaviour, bundle everything together into one set of hr files - works for expansions and regular plugins as before. I did change the default split size to 2GB as that seems to me to make sense.

Then there are two new options:

Split Data From Samples: This will put the data into its own .hr1 file with the suffix _data. The samples will then be bundled into .hr2, .hr3, etc. as needed. If the user only needs the data (because they installed the samples previously) then they just download and extract the .hr1. As it extracts it will still check for the next archive as before but will fail silently if its not there. However if one of the other archives is missing it will report an error as expected - I also improved the error message so instead of just saying Read Error, it tells the user which archive is missing. Data Only Update: This just compresses the data into an .hr1 archive and assumes the samples haven't changed and have already been compressed using the split option.

With the mod matrix system each connection can have a intensity and you should also be able to set it programmatically without the matrix floating tile using the API.

For targets that dont expose a mod chain you can just define a UI knob and give it a matrixTargetId. You‘ll loose the precision of the real mods but if it‘s acceptable then fine.

The modwheel could also be a global source modulator using a control modulator.

@bashfulsound It's a bug. I submitted a PR here but not sure if Christoph has seen it yet.

https://github.com/christophhart/HISE/pull/962