Handling multiple note changes in a single process call

[pongasoft]

I am just curious if you could share how you handle multiple notes in a single batch/process call. Every note event has a frameIndex which so far I have been ignoring.

What I am the most worried about is how do you handle multiple events in the same batch for the same note. I assume a Note Off / Note On would be a retriggering? But what if you had Note Off / Note On / Note Off in a single batch. Do you really handle this?

Finally, are the events(= property diffs) ordered in any way (like by frameIndex) or are they completely random?

Thanks
Yan
PS: if you want to share some code you can contact me privately...

[orthodox]

I am just curious if you could share how you handle multiple notes in a single batch/process call. Every note event has a frameIndex which so far I have been ignoring.

What I am the most worried about is how do you handle multiple events in the same batch for the same note. I assume a Note Off / Note On would be a retriggering? But what if you had Note Off / Note On / Note Off in a single batch. Do you really handle this?

I'm yet to make a device that handles notes, but I would definitely handle them with due consideration of the frame index.

Finally, are the events(= property diffs) ordered in any way (like by frameIndex) or are they completely random?

Jukebox C++ API Reference, 7.1. JBox_Export_RenderRealtime():

... The differences in the list are sorted by their respective frame position within the current batch. ...

[buddard]

I've found that most instruments out there don't seem to support multiple messages for the same note number in a single batch, notably all Gorilla Engine based instruments, but most others as well.

Reason's sequencer seems to take this into account when playing back. You can test this by creating a MIDI clip where you have the same note playing multiple times with no gaps in between. Send this to track again using a disabled player stack, and you'll see that the previous notes will be shortened "seemingly at random". This is to prevent note off and on messages for the same note from occurring in the same batch.

We've been doing the same thing with Sequences to ensure maximum compatibility with instruments while maintaining all note on messages sample accurate.

So in other words, if you implement a device that receives notes, you don't have to be so strict about handling multiple messages from the same note number within a single batch, but bonus points for doing it of course.

[Enlightenspeed]

Finally, are the events(= property diffs) ordered in any way (like by frameIndex) or are they completely random?

This bit could do with some explanation - I've never really researched this as I use methods that circumvent the problem

I'd be curious to know if anyone has an answer to this bit, though.

[orthodox]

Finally, are the events(= property diffs) ordered in any way (like by frameIndex) or are they completely random?

This bit could do with some explanation - I've never really researched this as I use methods that circumvent the problem

I'd be curious to know if anyone has an answer to this bit, though.

I quoted the SDK documentation on that ^^^

[Enlightenspeed]

This bit could do with some explanation - I've never really researched this as I use methods that circumvent the problem

I'd be curious to know if anyone has an answer to this bit, though.

I quoted the SDK documentation on that ^^^

Indeed, but what about diffs with no index, or diffs with the same index? What is the sort order? I've never noticed anything in the docs regarding this. Of course, it's not an issue to force a particular order, but it's not exactly hygienic either.

[Enlightenspeed]

Whoops, wrong thread

[pongasoft]

I quoted the SDK documentation on that ^^^

Indeed, but what about diffs with no index, or diffs with the same index? What is the sort order? I've never noticed anything in the docs regarding this. Of course, it's not an issue to force a particular order, but it's not exactly hygienic either.

I am not sure what you mean by "no index". There is always an index. It is usually 0 (for all cv values) and as far as I can tell it can be non 0 for note events (I am not sure if there is any other case where it can be non 0).

For same index, and same tag (= note) based on my recent experience, it is always in the order that they appear. For example you get a Note Off/Note on event in the order that it happened (if the note was on before, then you get note off then note on).

Of course I do not know if this is luck or guaranteed...

This is an example of events I got in the SAME batch (after messing around in the sequencer and using the razor tool / maximum zoom / no snap)

Code: Select all

onNoteReceived(48, 0, 0)
onNoteReceived(48, 100, 2)
onNoteReceived(48, 0, 7)
onNoteReceived(48, 100, 7)
onNoteReceived(48, 0, 10)
onNoteReceived(48, 100, 10)

48 is the midi note, 0/100 is velocity (so 0 means off, 100 means 0n) and the last parameter is the frameIndex...

Pretty crazy for a single batch!

[Enlightenspeed]

I am not sure what you mean by "no index". There is always an index. It is usually 0 (for all cv values) and as far as I can tell it can be non 0 for note events (I am not sure if there is any other case where it can be non 0).

Yup, CV is always quantized to 0, but also at the point of initialisation they will all be effectively 0, because they should all be the same.

So my interest was more "does the motherboard list govern the order of diffs arriving, if the frame indexes are all the same?". I can find this out on my own if no-one else knows - just thought I'd ask on the off-chance.

Apologies for derailing the thread.

Cheers,
Brian

[Enlightenspeed]

Yup, CV is always quantized to 0, but also at the point of initialisation they will all be effectively 0, because they should all be the same.

So my interest was more "does the motherboard list govern the order of diffs arriving, if the frame indexes are all the same?". I can find this out on my own if no-one else knows - just thought I'd ask on the off-chance.

Apologies for derailing the thread.

Cheers,
Brian

Hey folks,

Just posting up an answer to my own questions here in case anyone is following.

At initialisation the diffs run twice, the first run setting all values to 0, the second run then setting all values to their defaults. The patch values must come after this, but don't seem to write to the logs at all, which is... ...odd.

All fAtFrameIndex values are indeed 0 at initialisation, and for both runs.

The diffs are run strictly in motherboard order for this part of the process, which is very useful to know.

Cheers,
Brian