@oskarsh said in Buttons based on SVG:

namespace containing all your helpers functions

Oh thanks, yes I usally do that too.

@d-healey said in Buttons based on SVG:

You can do it with LAF

Oh, I just found this tutorial https://www.youtube.com/watch?v=badkm6QVNIA, which is a bit better than the Paint Routines method (using panels) that I knew.

Still, a built-in function in the component would be nice, since SVG is the new standard for resizable GUI.

Edit: After following that tutorial, I discovered that the method is indeed easy and convenient to use with multiple SVGs. Thank you!

@d-healey I have one main xml file named like the project and smaller stripped down versions for testing. Once a plugin reaches a certain level of complexity I like to branch out and create a new one to test complex features in isolation.

I often also have a Waveform, Filter, Arp combo in one xml to test the audio and the scriptfx networks. So that I can click click click to have a good sounding working setup. I mainly work with FX Plugins.

I think having a prompt where we can just press enter or escape would be a very good compromise. I think this already exists when changing projects.

This sounds great. Probably 10 or so color options on right click would cover 99% of usecases.

@Christoph-Hart fantastic, thank you!

@Lindon yeah, use globals and the FixObjectArray as I've mentioned in the other thread, it's exactly what it's made for.

@Christoph-Hart Ok I almost solved it using one TransportHandler.
I have 1 question though, if I have the "internalClock" running all the time, it is not possible to via "setOnTransportChange" get a "isPlaying = false" because the internalClock is still running (and I want it to keep running)
Is it possible to get the Transport state another way then via the TransportHandler?

@aaronventure Honestly I would much rather like to have a button in HISE which reloads and compiles the project again. That way we could use our favourite IDE like Sublime or VScode with all the bells and whistles.

We could write our own plugins for HISE Script, save snippets, use prettier code formatting and even code with Github Copilot. Using the built in Editor in HISE can sometimes be really painful, jumping between files and tabs.

Also its really annoying if you make HISE crash with some written code and need to jump into a external editor to fix the code so that HISE launches again because it would not let you edit the code.

I am currently working on a Language Server Extension for HISE Script (similar to this project) so that we can use the super reliable auto completion of VSCode.

https://github.com/Levitanus/HISEScript-Sublime

@Christoph-Hart please consider this feature and add a button which reloads and compiles the current .xml.

And again for future Dave, you can use registerAtParent() instead of the data object.

@obolig This actually created issues later down the road. The AAX plugins that resulted from this method were about 20X the size they should have been. I didn't realize this until I got to the signing stage of development. @gorangrooves informed me that the Runtime Library needs to be set to Multi-Threaded before you build the AAX SDK.

MT.PNG

This results in HISE building AAX plugins by simply using the regular export method. No need to adjust settings in the VS projects created by HISE/JUCE.

@bendurso This perhaps - https://docs.hise.audio/scripting/scripting-api/scriptpanel/index.html#setkeypresscallback

@aaronventure Ooops, you're right, from the JUCE docs:

Linkwitz-Riley filters are widely used in audio crossovers that have two outputs,
a low-pass and a high-pass, such that their sum is equivalent to an all-pass filter
with a flat magnitude frequency response. The Linkwitz-Riley filters available in
this class are designed to have a -24 dB/octave slope (LR 4th order).

Now that's what I call good documentation :)

@d-healey Yes that works, however it would be nice to have the same function for all component types.

I have a broadcaster that depends on the same script (component.get("id")

@tomekslesicki i can imagine giving the components a bigger height might work aswell and is less fiddly. At least in the default view where quite a lot of vertical space is unused.

@Dan-Korneff haha I've been trying to hack my way around adding this to hise for the past few months but can't get it to recognize the hise components lol

@aaronventure Alright, I've implemented a few of those things:

the routing matrix does show the peak volume as decibel text. You can right click and toggle "hold" mode, where it displays the maximum peak or the current one. The modulator intensity slider has now also a text label that should display the current modulation value. I could reuse the logic for the table popup label, which already tries to convert the mod value to the appropriate domain I've added a voice start plotter that somehow resembles what you proposed, although I have no idea how useful it is (the genesis of this was a little bit like taking numbers and C++ keywords and throwing it against the wall until something sticks), so please give me some feedback if you're actually using it.

but then scriptnode needs to have all the default modulators available as nodes without me having to rebuild them from scratch.

Yes, good point. I've spent the last days reproducing the most interesting HISE modules as thoroughly documented scriptnode networks so you can load and modify them to your likings (also I've added lots of QOL nodes along the process, like a container.branch that lets you dynamically route the input into a single child node which is super useful ).

https://github.com/christophhart/hise_tutorial/tree/master/ScriptnodeHiseModules

In order to increase the accessibility and learning effect, I've included a simple network that implements the core idea and then the full 1:1 representation with the gritty details and hacks.

It currently contains the LFO, the Table Envelope and the Harmonic filter, but let me know what other modules you would see as scriptnode network.