@ulrik Ah you're right, I was misunderstanding the snippet.

@d-healey Yeah just tested and I didn't help going further...

@d-healey delet dis nephew

On a serious note: it's a good point. Probably needs a snipper preprocessor which will execute the scripts, check if any startAsProcess calls were made or FileSystem deletion was used and warn the user about it or load it in the same window like the snippet browser with the ability to display the offensive lines.

Just checking the script for text wouldn't be enough as you can easily encode a blowfish string and hide it into an eval call.

@ustk genious, thank you!

@clevername27 it happens with sliders too, and without LAF as well

@guangcoder said in Help me understand Server.callWithPOST:

Server.setBaseURL("http://hise.audio");

This needs to be your server URL.

@Adam_G
Here is my project if you would like to take a look at it:

https://we.tl/t-hdRoNkpvt8

@aaronventure Oh wait, this SC is from an external screen. Effectively the rendering of the gradient is fine on the mac's retina
The blur doesn't improve though

@VirtualVirgin just delete them then.

@d-healey
Stupid mistake! I was referring to the zip file in startAsProcess(“”) and not the pkg file.
So the installer was not copied as I thought, but it was unpacked again.

Thank you very much, David. The correspondence with you helped me to find the error.

@ulrik As always mate ...perfect.

@d-healey

Three thumbs up!
Building matrices is on my todo list for next week, so this will come in handy!

@Christoph-Hart
I would think it's best just to let the user decide if they want to use it, like any other CC.

Now, upon testing the CC learn (I was curious to make sure it is blocking the consumed CCs at the output for use with MIDI plugins, and it does), but I must say that the CC learn being channel agnostic is not a good idea. This is not how most VST instruments will handle this.

Here in this simple MIDI utility I made, I just ran a test to check the channel filter operation in conjunction with the MIDI learn.

Screenshot 2024-11-12 at 11.28.22 AM.png

The MIDI learned control to CC#1 (Velocity Transpose Amount) is not affected by the channel filter, so even if my notes aren't going through, my CC values are.

The MIDI learns need to be channel selectable somehow in order to work in multitimbral settings where the VSTi endpoint is only meant to receive from one channel, otherwise you will have lots of unwanted CC messages going to the other channels/instruments.

Is there a way currently to make sure the CC learn can be filtered by channel?

I am not seeing channel selection in the MidiLearnPanel:
Screenshot 2024-11-12 at 11.59.53 AM.png

@d-healey said in Confusing results from message delay?:

@VirtualVirgin I have a chord detector script which adds notes to an array as they come in and then processes them. Sounds like a similar thing.

Here's a simple snippet that adds note numbers to an array in on note on and removes them in on note off. Works with notes played at the same time and sequentially.

HiseSnippet 731.3ocsUstSaCCE1tzfV6tngzd.xOKSHTaoEnBMMfdYqaqP0JCMooIjiiSiEI1QNNrUMs248FrcbRfFfJtTokeTky8udNemSFqjTVbrTgvUOYVDCgel0jYBseWeBWfF1Cgeg0HRrloryTc3rHRbLyEgwq7NiBbkxnzm+71CIADAkMWEBcpjSYehGx0y0Nd+OxCBFPbYmvCK3cq8GRkhtx.YBfmUrpihHzyISYGQLtUxB8dRrOB+ZKGhScB0ya6lN65UuUy1McbZ41Bz3rSmNc7Z2fzdqcnTDd09tbsTMQSzrXHoGJcmMwW9CQVANkGycBXFgFnIPkyTi55yCbGeYyIFgvkGOuUsRVq5UVi3t7qzOuk8xTC1yinXSCW5tfTiGAjvEfT4LHsl0DphGomawfmmZMT.SPOBLaJBkLeQk9.1pqD7Pn2LjbNafBDtJhZaWu9F1vOquW0pJ1TagDvs8ar+122yKQP0bovVJNBzdrn15U+U0JARJIvV.9LB.AL.2bJSab3njPGlplISURSylQIw9C8.aGDnXD2Ym3yTrZBvieW09lo2y6QmeEKTdwhRn4OrRFDXb2jyaX1vLWrk7.qIRq0F1WPBRXW4HLIt93c0G13kl0+K3nTLTv0GGwxkGHCbMiMy62lLfxGfvaeYXOhlX3G45.+hXJM2.GbO1EvFYFaohUOV74ZYDrSdKpDPhktIAD80Y1lc9bCP+3ZzICkQDy0yJdS3QP2qemz8GJDWyZLWS8WLFKs.LBcp+GXL+Hwys564wn54.rr0futrWDtmx+YYhlKlNhnU7ehvVv9vD3XJkAUWHXAPxsvkLrkL45FYSGXBS3lJ7W3I2XCiLN2XiKMhBITk7LZ1Vf4LzSR0.XRjdltB78BP1tAJcynXeNDtJdl4pbwTcq.atrAt0xFXqkMv1KafaurAtyxF3t2eflOZcPhVFls1fPiF2O8TBF2WP.FXJaE8OLLOJoG

Peek 2024-11-11 23-23.gif

Thanks :)
I'll check this out tomorrow.
I did end up solving for the delay problem by moving the rest of the code into a child container with another script processor.
Screenshot 2024-11-11 at 10.52.57 PM.png

Screenshot 2024-11-12 at 12.25.24 AM.png

The notes from the note recorder get delayed by 1 sample, and that gives room for the array to record all of the voices before sorting the order in the next module.
The basic problem that the delay solves is that the array cannot be sorted and reversed until all of the notes are in.

It is working so far:
Screenshot 2024-11-12 at 12.33.00 AM.png

I have a stray note off that I will try to clean up, but at the moment is not effecting the function.

@orange Thanks,You always save my day.

@VirtualVirgin said in Is there a method to force parallelization of code processing?:

@Lindon said in Is there a method to force parallelization of code processing?:

@VirtualVirgin this is not how MIDI works - as the MIDI Spec 1.0 makes very plain - MIDI is a serial protocol, so the notes must follow each other and cannot arrive at the same time....

I understand in theory the idea that that the MIDI messages are in serial.
If you generate notes for harmony, say using the Synth.addNoteOn() in HISE,
the order you generate them in the code will be the order they arise later on in a MIDI monitor, even if they are generated at the same sample. Note numbers generated out of sort order, say 74, 60, 77, will show up in the MIDI monitor later in that same order.

But in practice, the way I see it, MIDI messages that occur within the same sample are in some ways handled as if happening at the same time because a timestamp will read the same for all notes at that sample, and cannot be distinguished from using that information. So for time ID purposes they are the same.

MIDI from quantized DAWs, notation software and plugins generating harmonies will therefore return a time delta of "0" between messages in those vertical stacks (chords).

Screenshot 2024-11-10 at 12.17.09 PM.png

So not technically "at the same time", but from an ID perspective certainly categorized as the "at the same time" (timestamp).

Anyway, my question arises from trying to figure out how to handle MIDI messages occurring on the same sample when they need processing with a quick turnaround.
I'm sure you know a bit about it. I'll have some more questions later.

Yes, but no..... the MIDI spec says (if I remember correctly) that any receiving object needs only to act serially, so it can freely ignore the timestamp... so what you are doing is legal and accounted for - but no midi processor is required to process it in the same sample.... in fact given the laws of physics - they cant. - So it should come as no surprise when a midi processor of some sort (in this case HISE) doesnt behave the way you want.

David is right.

If you're creating controls using a helper function, simply create another one. You can then be increasing a counter which you can use to automatically set up the sliders in order for every control created.

Callbacks could be tricky, because if you simply put the function into the callback for another control, depending on the exact situation, you could end up with the same stuff executing twice, which may or may not be problem, but is something you should be aware of.

So you'll have to decide whether you'll be assigning a function as a callback for both controls, or do something else. You could use a broadcaster to automatically update the values of the simplified slider whenever the main control changes (attaching controls could be automatized with the helper function). The helper function should also let you automatize the assignment of a control callback for the simplified sliders: this would be an inline function defined outside of the helper function, which would be calling .changed() of the main slider. You could also automate the targeting of the correct pair component via ID by deciding on a naming scheme (e.g. Slider1_main and Slider1_simplified) and using the component argument of the callback function to get the target.

This not only simplifies your code by letting you only worry about the true functionality of a single callback function per control, but calling changed() for the main slider makes sure that that particular component gets set as "last touched" for the DAW, letting you maintain the mirage of it all being a "single control".

Another way would be to actually be using only a single set of controls, storing dimensioning and positioning data into JSON, creating a switch in your every LAF and changing all these properties when the simplified GUI button gets clicked. Depending on your GUI setup, you might also have to reparent controls (can you even do this beyond on init?), so this approach doesn't scale super well and would need a bit of tailoring for each individual GUI.

Ideally you use reserve(128) and a for loop where you push default values in the onInit callback.

Javascript usually doesn‘t complain about passing around undefined values but I found it to be the most frustrating source of issues while debugging (a little typo in the variable name goes through multiple function calls undetected and finding where it breaks is super annoying).

@VirtualVirgin You'd need to loop through the array and keep count in a variable