@ustk Awesome, that looks like it'll work great, though I'm getting slight flashbacks to similar control-layering jankyness in Kontakt.

For anyone reading this later, the solution is to script a panel to have mouse interaction slider behavior, or to use an invisible slider for mouse interaction and the panel only for drawing.

You can change which image is loaded using ScriptPanel.loadImage, and update the drawing of the panel with Graphics.drawImage.

David's tutorial covers a lot of relevant stuff here

I don't know what the situation is with IPP now in HISE, but the old dropbox link expired so here's an internetarchive link just in case: https://archive.org/details/intel-ipp

I started the slider as LaF but moved to a panel when I couldn't figure out an elegant way to do the animation, interesting that that's the one part not achievable with LaF.

Coming from Kontakt, the ability to have smooth transitions and (gasp) actual hover states for all controls is a huge win. The average user probably can't articulate the difference, but I think in testing a UI with smoothed hover states would get more positive feedback. When trying to sell something new to a group of people who have been used to Kontakt for potentially decades, I'm convinced this kind of UI polish can help make a HISE library stand out as better in every way than what people have been used to.

I believe I used a separate label so the text wouldn't be part of the hover target.

In context:

Easy to customize!

HiseSnippet 1890.3ocsXs0aaajEdnSTPk1Tfs.6S8oI5gcohYzMaqj.2z1DeYqQiSDhRylEKJJFSNRbfImgfbjsUKxh9ea+2rOs+C5dNyPJRJK4jZrqfgk3bt8clykYNbbpxmmkoRINsd6hDNw49MlrPpCOHjIjjSNj37YMFmxy3ZxKVjvxx3ADGm67WQpNMuKw74+7MufEwj97xkHj2oD97WJhE5xUG+seuHJ5XV.+sh3Jbu62dhuRdfJRMGPxcZzmjv7OmMi+JFx1VMHeGKKj37vF82aDm+3clFDv1YmfQiF8zm7zce5.1z96xNavnmt6vce7vm73oDm6cTfPqRmnYZdFnzWnBVLITcozZf2IxDmEwwGFPl.V1tL4fPQTv3hskLBw4tiK2jticS5O03TQfX45kaV+QCAZoDU2zb15lfzfeGPxoBjtqEReQiI9ohDcIEDO+gFmH07zoLH1TEJVdIa8uueiCT.GRc2X147iSgGVJg6t866QGrW+N62pkPFIjb5z4ResPIoAb+HVJeRjHfm5Jg3j2UdK7NWpNah3m4c9kVMiT9rHZlgC5ynEFhEDLlI4Q4BQeDsPHuEfkZZEna.Sy5VPADu3mqvAhp2FJ7OWBdMv1f8o85AAD4LN0fX8Rhg7T9RggLZ21gbwrPc6knl9P5P51T2Ma.fgNcPS774ZULSK.WLZAEzFMAcJpUk0MCWxf3JlY7RNKU11SmNmWwUMLkwtfehzVqsdN.Kot7.3+mAEGYs8ZePD.qLO52ot.1g+yzCSYylIjyZWWxSUyy3Exk6auVZVsNiigzX8aTy0fK6VDocm0g9KVdLzgm2+C0kCKlSulALqtZ.MDg5ykhXHT0Gnkx0ySk4II625CWOQqtoWlVsZbGByYqIfseA+XH9Mr.w75LWIqpjuimGEsj2JBtMc85FW8uIBzgEpdFWad1sCjc6NDxZpqVSFjUB0TPDNk4qmmqI5kveLolpUzfT1ksZVEauGrQceeaJTIFm39nUfNjGW.l2whlyAv7PpaIVA5qHgI4tiWeukL0olO92y2NJEYeDbyvb.ay6kVzs8YyrK0tCpjd8fjyKoQ7oZipZ0TL0Z+2S+5U2cZ0DzI55uDSDqSzytK3YATsuVtkzw.qd8dCVJZ2SgrH32PkJ.PoDpVzPKBCbphjsWM7+UOqL3tFXgRrL7lCdu0jBrpKTG686tmEw1cZdTjHIi+B0bY.l.9OrNbMOzqZZID1V84erbK2TwQmBm6VORY+Jq6kBc3oyizhjHAO34QIgrJQQglGa4bX6BWqdgrI7NqKZfirH2slGTDLLfAS0yoto7lRKVj477f.JC1rz5HNVTT1QGd.O1hJftu7TedBVDAAYnwrenwXgpTwOCG7jmA2JOBtVjtRVDrONn6PnTcyckx6h5xu.NXC6MgoRlG55i8l4A3h4w0KvhPHdlyPLJ4gvg+um1iV59WhIMVOuoY0rhxWaUtQKd8612aP29UXy2bjWfKtBf2JHA72YaFFW8+dqSw.do8sIfO3Yql7.GqTHd4h.vpH090XfAYa3IjpYo487gCIKQplkZOIxcvHSC1Aihyn+S5n9SSxJ3JkmfmjbRbLOP.WCKZQ9N1MDisJsH7dM.C24Xsth4Ttsgi45N.OoacBaX4qAE.alnFJ7DURtMQ49.Bulaz382rweDZ7c16lL9Wgr7IX7aXyaM6bUSVhERuX1UkmbC02IPv6TlNrKPrfMfkx6CXIxtxEYFUg0N858Rt9ujUb4SJSFPgpHSkN1Xe1CZAyQjoowKlTbsy5WTssMn11au9l+.8VvqsajTmphVdWlBZuVlSAuJbUApbNm2xNpgPOLSFHdPwJrWo81RAf7YtzHv2Ccw2n.CqXBnossUcwJo7.6IIF8XtQ30iKWycb8UwIJITv4YaLzoEDm.hYpHd2jT7RWseaHu3V7WpROO6Az1v4dGIgqZxw1F+PhFRXbw1AeX+k1RIekRyesz0nRH5QWkzzoqkVNzhvTv0PNO4byB5JmGeFOspCgLBSJUe7q68oM9kucrkJLpjmHE5Wmvye9XUT.NVE96qOrFIetGbrsbDBrpMCs84ECsgiNPDA3z11cZhA73Dx6X97u9FxObxgPsagZ.MBVAN0SKPmw4P9Ev711YAa13Pd14Pgrg27.LLL3G0nWQbZ37H.yKveLD9gcbFPk2694y0uxvLHiNvxUGeoXs5CrPb9xFaZhERQUDZoeC9fVpLyGWk7qjUVcHZGB429Ux0GGFFDWELOhoqOcN9dKxI.4L0FIFG6UlIzKp9dM9cLxd+abj8OUH9EMFKf6trdLt0ZvHjO7+CLl+hN97FGMcJ2WWBv61332eaeqFeDyam7bFz6OUfYhuZd7DHL6yww4gb0LLduEVQYetuM9SHS3x.yCXlSNwAEIgHwAEDIwL+T0O4aqCwWkxmYVAvjz7plZ13T7Y5fxBvh84XHk+m78qqpqI3vaqf6baEb2aqf6caEbzsUvGeaE7IebAwNREuTFnrgPNc7QlFlNNGYZYYxVI+WP3nMW1

@Robert-Puza Any time you are compiling something on Linux and you get a "package not found" error or something of that sort, the first thing to do is check if your distro has a slightly different name for the package and install it. Some distros include "lib" at the start of library packages, some don't, sometimes there's a - in one distro but not in another. This is why instructions don't always include one line you can copy paste to install dependencies: each distro needs a slightly different list.

As you're on Mint, you use apt. I would type "apt search webkit2gtk" and see what comes up. I believe Mint does have the package, but the correct name is actually "libwebkit2gtk-4.0-dev", which is why it didn't get installed when you copied the line from the readme.

Either way, using David's fork is a good idea.

I would really just prefer a way to use an external editor. After several weeks of intense scripting work using only the HISE editor, the low contrast color scheme, lack of syntax highlighting, lack of keyboard shortcuts, slower response time, and many other quirks make me far prefer the (sadly proprietary) Sublime text.

I don't doubt that it will eventually be on par, but for the sake of getting work done I really need to be in Sublime at the moment. If the fastest way to reload the script is to load the xml I'll just keep doing that.

@Robert-Puza You don't have to re-compile, you can just copy the "HISE Standalone" executable. You only need the source when exporting a plugin or compiling HISE itself.

@Robert-Puza I don't know of any third party software that works with ncw. You'll need to load the library in Kontakt, and go file > save as and uncheck "Compress Samples". The good news is Kontakt works well with WINE.

Mostly I find the script editors are a little slow. It's difficult to quantify but typing, navigating, and selecting text definitely feels less responsive than in a typical text editor. When typing, some characters appear with a microdelay.

If the ScriptWatchTable is onscreen, general performance gets worse.

Resizing panels is verrry slow, but I think that's been the case forever.

Dragging in the mapping editor is usually quite slow, the selection refreshes maybe three times a second. Releasing the mouse during a selection sometimes causes HISE to freeze. The number of samples mapped doesn't really seem to have an effect. -- I just noticed this appears to be affected by the area of the mapping window.

For me, with OpenGL enabled the application is next to unusable, all clicks take seconds to register if they do at all.

So, how's performance for you all?

Fedora 41, Wayland session, i7 4790k, RX 6600 XT. Build is from Master, built in a Debian 11 VM.

Ah it's a permissions thing. If you go into settings and allow full disk access to either Xcode or Projucer (I just enabled both), it builds and opens properly.

@Christoph-Hart I would not at all be opposed to having the common curves as presets, but it's quite important to be able to adjust the curves for feel.

@Christoph-Hart Me, 100% of the time. I adjust it until the xfade feels right. I also pretty much never want a linear fade from one to the other, but expand the dynamic range by making the lower dynamic fade down in the lower range.

@d-healey I know you technically CAN, but I mean in a way that is easy to work with, and doesn't require using RR groups for two different purposes.

@Christoph-Hart You've probably thought of this already, but just in case:

Ideally the legatos would be matched to the sustains, not the other way around. The start of the legato sample should be matched to the end of the source sustain, and the end of the legato sample should be matched to the start of the target sustain.

An envelope seems simplest to me, or a compressor/expander. In any case:

• Apply a gain offset to the legato sample, to match it to the source sustain
• Apply an envelope to the legato sample, to match the end of the legato sample to the target sustain

The envelope attack time and curve might be worth exposing as options, or maybe a fixed curve is enough.

I have spent a lot of time working on legatos and have equally many opinions on them, so I am very excited to see what you are working on.

@Christoph-Hart For automatic gain matching, I'll gladly put all my legatos in the same sampler :)

I don't see this particularly affecting legato. I would still put sustains in one sampler and legato samples in another, which makes it easier to adjust envelopes and manage the sample maps.

The biggest change for me here is being able to use dynamic xfades and round robins simultaneously in one sampler.

@Christoph-Hart In your example samples get assigned both an RR and a group XFade, were you planning to add separate controls to manage and filter group xfades?

Edit: I just noticed you said you'd keep the basic note/vel mapping. I'll boil my question down to "Does this mean XFade groups would be added as an axis separate from RRs, and will I still be able to use Enable MIDI Selection?"

Original novel:

This looks like a dream come true as someone traumatized by too many huge orchestral libraries done in Kontakt.

I'm curious how you see it interacting with the existing controls. Is the idea that in this mode, samples could only be played back with Sampler.addGroupFilter(), or would assigning a sample a note and rr value still put it in the mapping editor? The xfades would need a way to be edited, were you thinking to move the existing group xfade controls out of the RR groups? Or would it all be managed by script?

The library I'm working on would not have been possible without HISE's "Enable MIDI selection", which let me adjust volume, pitch, start, and end of my legato samples to match them to the sustains. In Kontakt, without combined mics, it's almost impossible to do, though Jasper Blunk masochistically manages it with table modulators and force of will. Spitfire and OT probably do it with their dedicated (proprietary) players. Point is this has always been out of reach for me.

The downside was I needed to use RRs for variants -- vowels in this case. Crossfaded dynamics got split out into separate samplers and controlled with a global modulator.

If "XFade" is added as a native concept, and if it were added as a separate axis, similar to how RRs are now, with a dropdown to filter for a given xfade layer in the mapping editor, that "Enable MIDI selection" workflow would still be possible.

I'm biased, as almost all libraries I've worked on have multiple arts, some with rrs, some with xfaded dynamic levels, some with both. I think supporting keyswitching natively is maybe overkill, as separate samplers for separate articulations is logical and works fine, but maaaaybe it's worth natively supporting crossfaded dynamic levels in the UI?

Wall of text from 2014

Why am I not surprised

Wouldn't you know it, right click menus work fine on X. Amazingly given the reputation, I think it's the first real Wayland issue I've run into!

@d-healey I had similar issues, including inability to adjust sample properties, samples not playing back, and other weirdness, when some of my samples were mapped using a different path than the project folder.

I have a soft simlink called "WIP Libraries" in my home directory that I access all my projects through. Some samples were loaded with their canonical path and not through the link.