VstMidiEvent for the braindead: NumEvents question.
-
- KVRer
- Topic Starter
- 14 posts since 4 Apr, 2010
Currently I'm developing my own vst plugin and I can't get the idea about the maximum number of events that a host can send to a plugin in one block.
Is that somehow related to sampling rate, asio buffer size and the speed of midi(31250 bits per second)?
Is that somehow related to sampling rate, asio buffer size and the speed of midi(31250 bits per second)?
-
- KVRAF
- 1940 posts since 16 Aug, 2004 from Vienna, Austria
There's no defined maximum (except for the obvious, which is 2147483647 ...). And no, it isn't related to any of the sizes, since the MIDI speed doesn't have any meaning as long as the MIDI message doesn't leave the computer and travels on a real MIDI cable.
If I was you and would have to buffer the events, I'd allocate a ring buffer for 1000 messages and ignore any overflow. Chances are high that you won't ever see more than 20 messages per block, but 1000*sizeof(VstEvent) isn't really something to worry about these days.
If I was you and would have to buffer the events, I'd allocate a ring buffer for 1000 messages and ignore any overflow. Chances are high that you won't ever see more than 20 messages per block, but 1000*sizeof(VstEvent) isn't really something to worry about these days.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
-
- KVRian
- 522 posts since 19 Jul, 2007 from Netherlands
Note that different types of events have different sizes...arakula wrote:If I was you and would have to buffer the events, I'd allocate a ring buffer for 1000 messages and ignore any overflow. Chances are high that you won't ever see more than 20 messages per block, but 1000*sizeof(VstEvent) isn't really something to worry about these days.
[2c]
-
Jeff McClintock Jeff McClintock https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=56398
- KVRist
- 413 posts since 30 Jan, 2005 from New Zealand
Also bear in mind you don't usually need to copy the events sent from the host, the pointer to the host's events passed by processEvents() remains valid during process(). Rather than laboriously making a copy of the events, just copy the pointer...
long SeVst::processEvents (VstEvents* events)
{
m_events = events;
return 1; // want more
}
void SeVst::processReplacing(float **inputs, float **outputs, long sampleframes)
{
if( m_events )
{
for( int i = 0 ; i < m_events->numEvents ; i++ )
{
VstMidiEvent *e = (VstMidiEvent *) m_events->events;
..etc
long SeVst::processEvents (VstEvents* events)
{
m_events = events;
return 1; // want more
}
void SeVst::processReplacing(float **inputs, float **outputs, long sampleframes)
{
if( m_events )
{
for( int i = 0 ; i < m_events->numEvents ; i++ )
{
VstMidiEvent *e = (VstMidiEvent *) m_events->events;
..etc
- KVRAF
- 7888 posts since 12 Feb, 2006 from Helsinki, Finland
Jeff McClintock wrote:Also bear in mind you don't usually need to copy the events sent from the host, the pointer to the host's events passed by processEvents() remains valid during process(). Rather than laboriously making a copy of the events, just copy the pointer...
long SeVst::processEvents (VstEvents* events)
{
m_events = events;
return 1; // want more
}
void SeVst::processReplacing(float **inputs, float **outputs, long sampleframes)
{
if( m_events )
{
for( int i = 0 ; i < m_events->numEvents ; i++ )
{
VstMidiEvent *e = (VstMidiEvent *) m_events->events;
..etc
Indeed.. while this might seem theoretically "against the spec" it's something that every practical host must support anyway, because plenty of us have been doing this for ages. Just make sure you always clear the pointer at the end of the processReplacing call (and I'd clear it in suspend() and/or resume() as well, just to be safe).
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
You guys are brave. Can you really get away with that in ALL hosts? (FLS typically being the one with the least generous interpretation of the spec. If you don't plan a contingency for EVERYTHING and EVERYTHING, that host will bite you!)
-
- KVRer
- Topic Starter
- 14 posts since 4 Apr, 2010
thank you guys so much for the explanation. now I have a clear picture how everything is running
-
Jeff McClintock Jeff McClintock https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=56398
- KVRist
- 413 posts since 30 Jan, 2005 from New Zealand
No, not against the spec. Why would Steinberg design the spec to force you to copy some memory that's already allocated for you? Why would you want to waste cycles in a real-time context?mystran wrote:Indeed.. while this might seem theoretically "against the spec" it's something that every practical host must support anyway.Jeff McClintock wrote:Also bear in mind you don't usually need to copy the events sent from the host, the pointer to the host's events passed by processEvents() remains valid during process(). Rather than laboriously making a copy of the events, just copy the pointer...
ALL hosts maintain the event list during the process call. That is the spec. No need to overcomplicate your code.
-
- KVRAF
- 1940 posts since 16 Aug, 2004 from Vienna, Austria
Not against the spec, but also not in the spec - the VST SDK 2.4rev2 documentation doesn't say anything about the lifetime of the events. While the behavior would make sense, it's pure conjecture that ALL hosts maintain the event list.Jeff McClintock wrote:No, not against the spec. Why would Steinberg design the spec to force you to copy some memory that's already allocated for you? Why would you want to waste cycles in a real-time context?
ALL hosts maintain the event list during the process call. That is the spec. No need to overcomplicate your code.
That said, mine do
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
Absolutely.arakula wrote:Not against the spec, but also not in the spec - the VST SDK 2.4rev2 documentation doesn't say anything about the lifetime of the events. While the behavior would make sense, it's pure conjecture that ALL hosts maintain the event list.Jeff McClintock wrote:No, not against the spec. Why would Steinberg design the spec to force you to copy some memory that's already allocated for you? Why would you want to waste cycles in a real-time context?
ALL hosts maintain the event list during the process call. That is the spec. No need to overcomplicate your code.
That said, mine do
Also, nothing to say processEvents will only be called once between process calls. (If at all!) Or that the events will be sorted in order of their deltaFrames values.
And again, if you want to test under the worst case, least generous, assumption-smashing host possible, its name is FLS. It's like they went out of their way to find ambiguity in the VST API and chose the path of most resistance at every point.