@Orvillain

To avoid aliasing you need to be able to control which harmonics are present in the signal either using FFT or a Filter. You'll need to be able to do upsampling in good quality which is why filter design is important I'm not talking about biquads, rather FIR filters. If you can process a signal with FFT in C++ and back again, and you can use FIR filters to do oversampling then you should be able to do a WT engine.

Here is a good resource

@Orvillain

Oh yeah yeah, I found faults with the provided script too. I had to do some casting. I think that's correct.

@Christoph-Hart Lovely stuff!! Thanks for letting me know!

I'm working in HISE right now. Let me pull the latest develop branch and see how I get on. Will report back.

EDIT: Yep. All good here!!

@d-healey Doh. No, I totally forgot. It is fine now.

smacks wrist

@Orvillain said in Accessing midi processor name from within connected script:

I'm fairly confident this will enable me to have my generic script,

That's how I do it

@d-healey Oh! Nice one Dave! I hadn't spotted that thread, doh!

@d-healey said in How do I load a midi script programmatically?:

@Lindon said in How do I load a midi script programmatically?:

{PROJECTS}\mysub\yoursub\afile.ext

You don't need a slash after the wildcard, and if you use forward slashes only it will work on all systems. Don't know about the lopp player though.

yeah that might work for you but as I say its at the very least unreliable for me, it might be cases of paths without {PROJECT_FOLDER} in them

@Christoph-Hart said in How do I get the pixel data under the mouse cursor?:

@Orvillain I could add a wrapper to Path.contains(), then you can at least create shapes with hit zones using paths and test the hover state with the mouse positions, this relieves you from the burden of weird geometry and a JSON file.

Hey Christoph, that sounds like it would be very useful.

@aaronventure No idea tbh!!

@Orvillain good PSA, thanks!

@Orvillain @aaronventure Good points.

I've reached through the archives. This one -

Phase-aligns two IRs in real-time (guitar chains). Morphs in real-time between those two IRs. (guitar chains). Employs non-linear IRs ( guitar modelling). Print new IRs (linear) of the plugin's current state.

As I recall, the phase alignment made a big difference. I can try to dig this one up some more if that's helpful, but it's not HISE. Here's an early build that shows the IR designer, and some other IR-related stuff.

2b60b223-e357-4e85-8a3b-baea75661952-image.png

This one began wrapping the low-level controls into meta-controls.

43ce3ee5-bd8c-4b5b-a50b-2695cf88dea6-image.png

If you'd like any information on any of this, pls let me know.

@Orvillain

Blooming blooms of bloomington! That was a lot easier than I had thought it was going to be! More or less the example in the documentation was all I needed to do. Here's the code for setting up the broadcaster. This happens in the main interface onInit function.

const var b = Engine.createBroadcaster({ id: "sampleListener", args: ["eventType", "samplerId", "data"] }); b.attachToSampleMap("Kick_sampler", "SampleMapChanged", ""); b.addListener("", "funky", function(eventType, samplerId, data) { build_sampler_routing(samplerId); });

This triggers a function called build_sampler_routing, which takes the samplerId in as an argument:

inline function build_sampler_routing(sampler_id) { local parts = sampler_id.split('_'); local slot_name = parts[0]; local routing_matrix = slots[slot_name]['sampler_routing_matrix']; routing_matrix.setNumChannels(sampler_channel_count); local slot_default_routing_data = default_channel_data[slot_name]; for (channel in slot_default_routing_data) { local channel_data = slot_default_routing_data[channel]; routing_matrix.addConnection(channel_data['source_idx'][0], channel_data['sampler_output_idx'][0]); if (channel_data['source_idx'].length > 1 && channel_data['sampler_output_idx'].length > 1) { routing_matrix.addConnection(channel_data['source_idx'][1], channel_data['sampler_output_idx'][1]); } } }

That's how I needed it to work for my script anyway. Your mileage may blooming well very.

Also shout out to @d-healey - signed up to your patreon guv, and learnt about broadcasters from your video. Would definitely love to see more there. Seems like broadcasters can handle a lot of the heavy lifting when it comes to communicating between different parts of a plugin.

@Christoph-Hart said in Phase coherence broken when SendContainer comes before Sampler in the module tree:

Actually I can‘t think of a use case where having the container before the source would be useful

You may want the container to be after the source but not want it to be at the end of the chain. I can't think of a particular use case, but it may come up in the future.

adb32698-490b-4f2f-9b53-0def7a2c5f5b-image.png
e3fe4cc0-b597-4155-9089-612fadbcbd13-image.png

This is how I handled it:

Main container. Inside:

Sampler Send container

Sampler FX:

A series of send effects. Each one selects a channel pair (0 being 1+2, 2 being 3+4, etc)

Sampler routing matrix:

For the outputs that I need to duplicate.... route the left through to the container inputs. Leave an empty socket for the right. Any top row sources that are genuinely stereo just route through as normal.

Send Container routing matrix:

Connect the top row channels to the 'empty sockets' for the right source. This means that 1+2 now carry the same signal. 3+4 carry the same signal.

Main container:

Now you can add Simple Gain insert effects and assign them to the pairs. This gives you a volume control for the dual-mono pairs, as well as the regular "true stereo" sources.

@Orvillain I think there are several techniques to detect transients, and it is often a blend of many of them.

It depends on the frequency (so I think that it shouldn't be bad to "listen" to a certain frequency range) apply an exponential factor to the signal in order to improve the ratio of the transients it contains don't detect below a certain threshold (but that becomes amplitude dependent)

Why taking not the derivative of the amplitude and check for the a minimum slope... but that is just an idea, and here again the input has to be filtered

if the detection is not real time, I would probably go with a waveform detection above a specific threshold, and prevent to detect the next transient after a specified amount of samples. Well, after thinking to it this can be real time too...

@Orvillain if you put it into scriptnode it would.

Pretty sure you could just do it with code in the processBlock (it's undocumented; print the channel obj to see what you can access) by referring to a global array where you set the gain and pan data.

But it will definitely work in scriptnode. Maybe you can just do a gain node and a clone node, then access each gain's parameters directly without creating 94nnetwork parameters and connecting them, but Chris is sitting on the API as its unfinished so you'd have to ask him.

If each of these is a separate voice, it's more efficient to do a gain modulator and just set the gain and pan in on voice start by adding a script voice start modulator.

Then you can just send the gain and pan data with the new globalcable methods alongside the note id (even though sending 0 doesn't work in scriptnode at the moment).

Definitely multiple samplers with a reduced voice count per instance (depending on the decay time of the drum, a voice between 16 and 64 should be enough).

Having 8-12 sampler modules is totally fine.