Is there a method to force parallelization of code processing?
-
@VirtualVirgin You're printing the notes in a loop which could be part of the issue. Instead use the script watch table to monitor the values in the array in realtime, or use
Console.print(trace(myArr)); -
@d-healey said in Is there a method to force parallelization of code processing?:
@VirtualVirgin You're printing the notes in a loop which could be part of the issue. Instead use the script watch table to monitor the values in the array in realtime, or use
Console.print(trace(myArr));I don't think so.
The print of the array length is outside of the loop, so the console should not be showing the print of the array length in between each print of the array contents.
It should show all 5 prints of the length at the very end of console, and each should read as "5".
(That is, if it were operating in parallel at each statement) -
@VirtualVirgin Can you make a minimal snippet that demonstrates this?
-
@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....
-
@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).
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. -
@VirtualVirgin said in Is there a method to force parallelization of code processing?:
but from an ID perspective
The event ID will always be unique.
-
@d-healey said in Is there a method to force parallelization of code processing?:
@VirtualVirgin said in Is there a method to force parallelization of code processing?:
but from an ID perspective
The event ID will always be unique.
"ID" here referring to the ID of the timestamp (0 samples difference), not the Event ID.
-
@VirtualVirgin I'm suggesting you use the event ID to avoid clashes in your array. A minimal snippet would really help to understand exactly what the issue is and find a solution.
-
@d-healey said in Is there a method to force parallelization of code processing?:
@VirtualVirgin I'm suggesting you use the event ID to avoid clashes in your array. A minimal snippet would really help to understand exactly what the issue is and find a solution.
Yes, I was thinking about using a combo of timestamp and Event ID for each note.
At the moment though my problem solving test has switched over to a different, but related conundrum. I'll put that in a different post in a few.
-
@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).
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.
