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...
Handling multiple note changes in a single process call
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 2021I 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?
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. ...
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.![Very Happy :-D](./images/smilies/icon_e_biggrin.gif)
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.
![Very Happy :-D](./images/smilies/icon_e_biggrin.gif)
- Enlightenspeed
- RE Developer
- Posts: 1110
- Joined: 03 Jan 2019
This bit could do with some explanation - I've never really researched this as I use methods that circumvent the problem
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
I'd be curious to know if anyone has an answer to this bit, though.
I quoted the SDK documentation on that ^^^Enlightenspeed wrote: ↑14 Oct 2021This 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.
- Enlightenspeed
- RE Developer
- Posts: 1110
- Joined: 03 Jan 2019
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.orthodox wrote: ↑14 Oct 2021I quoted the SDK documentation on that ^^^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![]()
I'd be curious to know if anyone has an answer to this bit, though.
- Enlightenspeed
- RE Developer
- Posts: 1110
- Joined: 03 Jan 2019
Whoops, wrong thread
Last edited by Enlightenspeed on 14 Oct 2021, edited 1 time in total.
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).Enlightenspeed wrote: ↑14 Oct 2021Indeed, 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.
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)
Pretty crazy for a single batch!
- Enlightenspeed
- RE Developer
- Posts: 1110
- Joined: 03 Jan 2019
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
- RE Developer
- Posts: 1110
- Joined: 03 Jan 2019
Hey folks,Enlightenspeed wrote: ↑14 Oct 2021Yup, 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
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: No registered users and 0 guests