@d-healey this is the doc…

https://docs.hise.audio/scripting/scripting-api/midilist/index.html#setvalue

But in reality, I think it can store a 32bit integer

@d-healey I think I must have misunderstood the online docs (or they are out of date), as it appears to state the values must be between -128 and 128. But testing, it seems I can have 9 figure integers. Perhaps it means there are indexes between -128 and 128?

Perhaps missing something obvious, but how can I use MidiList to store times, when it only seems to be able to store integer values between -128 and 128?

@d-healey great! Just wanted to make sure we were talking about the same Timer.

Wonderful. That’s been super helpful, thanks! I’ll see what I can come up with using this method.

@d-healey ah, great. So is this something different from…

https://docs.hise.dev/hise-modules/midi-processors/list/scriptprocessor.html#the-ontimer-callback

Which says it is limited to 40ms…?

@d-healey okay, this makes sense. I thought I read something about the timer being limited to 40ms intervals, though? Not sure if this would have the resolution I need.

That aside, I have a follow up question regarding MidiList…

I’m logging quite a bit of information per note on event, and currently must admit to having them in an array, where each array index has an object. So I might set and get Middle C meta data at noteLog[60]["noteLength"] or noteLog[60]["noteOffTime"] etc.

Is there significant advantages to separating those all out into discrete MidiLists?

const var noteOffTime = Engine.newMidiList();
const var noteOnTime = Engine.newMidiList();
etc.
etc.

@d-healey in my case, I’m looking to analyse the amount of time between the last note off and the new note on. But let me see if I’ve got this correct…

I would set a timer (let’s say, 10ms intervals).

I log the time of the note off event. I log the time of the new note on event. Timer callback checks if logged new note on time minus logged note off time is less than 50ms. If yes, trigger Sample A, if no, trigger Sample B.

@d-healey great, so you understand what I’m trying to achieve… surprisingly tricky to actually put into plain English!

I suppose I was worried about having loads of timers pinging off. This is a piano library, so I’d need to set a timer on every single noteOff event, and it would need to be polyphonic! Should I be worried? What’s the most CPU friendly way of doing this?

@Lindon how would that work in practice, though? I can’t work out how to say “50ms has now passed and another noteOn event has not been triggered, so you can now go ahead and trigger sample B”.

Here’s two different scenarios with an event timeline…

Scenario A

0ms — NoteOn eventID1
250ms — NoteOff eventID1
270ms — NoteOn event ID2

At 0ms I trigger an attack sample (let’s call it attackSampleX). I don’t want anything to be triggered at that 250ms NoteOff event point. I want that initial NoteOn voice to keep holding. I want to wait for 50ms to see if we have another event incoming. As it happens, in this scenario A we do have another note on event, so at the same time (270ms) I trigger the new NoteOn attack sample (we can call that attackSampleY), I also want to trigger the appropriate “legato” release sample for the first note on event (ID1). Let’s call that “ReleaseSampleLegato”. I have managed to script this no problem using engineUptime, using Synth.playNote from the noteOn callback.

The issue is Scenario B

0ms — NoteOn eventID1
250ms — NoteOff eventID1
300ms — (there have been no new events)

Triggering AttackSampleX on 0ms. After that, as before, I don’t want anything to be triggered at that 250ms NoteOff event point. I want the voice to continue holding until 300ms in case there are any new noteOn events. In this Scenario B there was not, so I want to go ahead and trigger a normal release sample (say, “ReleaseSampleNorm”)

I can’t work out how to do this, and it’s driving me crazy 🤪

I am hitting a brick wall with the following...

For any given note's noteOff, I want to have a 50ms analysis window to allow me to determine which noteOff sample to trigger. If another noteOn (on the same midi note) is triggered within that 50ms, then we will trigger release sample A. If the 50ms window elapses without a repeated note, we will trigger sample B.

It seems like this should be straight forward enough, but I'm struggling to cime up with an elegant solution (in truth, I'm struggling to come up with any solution!).

I am reluctant to use a timer, as my instinct tells me this will put heavy strain on the CPU, but perhaps I'm wrong?