Handling multiple note changes in a single process call

This forum is for developers of Rack Extensions to discuss the RE SDK, share code, and offer tips to other developers.
User avatar
pongasoft
RE Developer
Posts: 367
Joined: 21 Apr 2016
Location: Las Vegas

Post 10 Oct 2021

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...

User avatar
orthodox
RE Developer
Posts: 1707
Joined: 22 Jan 2015

Post 10 Oct 2021

pongasoft wrote:
10 Oct 2021
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.
pongasoft wrote:
10 Oct 2021
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. ...

User avatar
buddard
RE Developer
Posts: 1006
Joined: 17 Jan 2015
Location: Stockholm

Post 11 Oct 2021

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. :-D

User avatar
Enlightenspeed
RE Developer
Posts: 876
Joined: 03 Jan 2019

Post 14 Oct 2021

pongasoft wrote:
10 Oct 2021
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 :D

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

User avatar
orthodox
RE Developer
Posts: 1707
Joined: 22 Jan 2015

Post 14 Oct 2021

Enlightenspeed wrote:
14 Oct 2021
pongasoft wrote:
10 Oct 2021
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 :D

I'd be curious to know if anyone has an answer to this bit, though.
I quoted the SDK documentation on that ^^^

User avatar
Enlightenspeed
RE Developer
Posts: 876
Joined: 03 Jan 2019

Post 14 Oct 2021

orthodox wrote:
14 Oct 2021
Enlightenspeed wrote:
14 Oct 2021


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

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.

User avatar
Enlightenspeed
RE Developer
Posts: 876
Joined: 03 Jan 2019

Post 14 Oct 2021

Whoops, wrong thread
Last edited by Enlightenspeed on 14 Oct 2021, edited 1 time in total.

User avatar
pongasoft
RE Developer
Posts: 367
Joined: 21 Apr 2016
Location: Las Vegas

Post 14 Oct 2021

Enlightenspeed wrote:
14 Oct 2021
orthodox wrote:
14 Oct 2021


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!

User avatar
Enlightenspeed
RE Developer
Posts: 876
Joined: 03 Jan 2019

Post 14 Oct 2021

pongasoft wrote:
14 Oct 2021
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

User avatar
Enlightenspeed
RE Developer
Posts: 876
Joined: 03 Jan 2019

Post 18 Oct 2021

Enlightenspeed wrote:
14 Oct 2021
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

  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot] and 1 guest