Hello everybody,
is there a risk (or a consequence) if I call multiple times sdkSetEvtSize within the same call to onProcess() ?
I have a module that parse all incoming MIDI events and generates an array on output, but the size of the output array depends on what has been detected in the incoming MIDI stream (so I can't just count the number of MIDI messages and compute the related output size)
So what I do for now is :
- parse next MIDI event in the input array
- if it is a recognized MIDI event, I add two in the size of the output array
- and I add the computed data at last position of the newly computed
If there are three MIDI events on input when onProcess() is called, then I call sdkSetEvtSize three times. I am afraid that there is a kind of dynamic allocation, for which multiple calls would be problematic.
And second question (more for the Sensomusic team) : are arrays only limited to TColorUsine and TPrecision types, or can I also make arrays of ptBitwise ?
Thanks
Benoit
Multiple call to sdkSetEvtSize
-
sm_jamieson
- Member
- Posts: 551
- Contact:
I do what you do with adding midi messages several times in onProcess() or onCallback() without any problems.
Each time, I do getEventSize() (saved storing the size elsewhere), add the extra message count, then do setEventSize().
However, when I tried that with much larger event sizes (over 100 bytes), I found that Usine did not like it, so I created an event and then copied that to the output event when it was all set up.
All bear in mind that each time setEventSize() is called, the event memory may be relocated, so if you are using a pointer from sdkGetEvtDataAddr(), make sure you call this again to get the possibly changed pointer.
About size of arrays, the official "Array" are only color and float (TPrecision), but you can create an event of any size and copy any type of data into it using sdkGetEvtDataAddr(). In that way you can create an "array" of, say, ptBitwise, but it will not be recognized by any Usine modules, only User modules written for it. Some Usine modules will pass through this array transparently (e.g. the flow modules).
You can cast the event data address to whatever type you want to put in it, e.g.
ptr = (tMyType *)UM->sdkGetEvtDataAddr(evOutBuff);
It you send your new event type into ptBitwise parameters, it will not be modified in any way.
See also the previous post titled "How to create an integer input/output event ?"
Simon.
Each time, I do getEventSize() (saved storing the size elsewhere), add the extra message count, then do setEventSize().
However, when I tried that with much larger event sizes (over 100 bytes), I found that Usine did not like it, so I created an event and then copied that to the output event when it was all set up.
All bear in mind that each time setEventSize() is called, the event memory may be relocated, so if you are using a pointer from sdkGetEvtDataAddr(), make sure you call this again to get the possibly changed pointer.
About size of arrays, the official "Array" are only color and float (TPrecision), but you can create an event of any size and copy any type of data into it using sdkGetEvtDataAddr(). In that way you can create an "array" of, say, ptBitwise, but it will not be recognized by any Usine modules, only User modules written for it. Some Usine modules will pass through this array transparently (e.g. the flow modules).
You can cast the event data address to whatever type you want to put in it, e.g.
ptr = (tMyType *)UM->sdkGetEvtDataAddr(evOutBuff);
It you send your new event type into ptBitwise parameters, it will not be modified in any way.
See also the previous post titled "How to create an integer input/output event ?"
Simon.
-
imodularsynth
- Member
- Posts: 36
- Contact:
Hi Simon,
thank you for your explanations. Your comment about the relocation makes me think that there is a kind of dynamic allocator somewhere, which I don't like too much for a real time function like onProcess.
I will try to rearrange my code to make only one allocation at the beginning, by precomputing something like a buffer (I am rather sure that there will never be hundreds of messages received during one call to onProcess.
Thanks again
Benoit
thank you for your explanations. Your comment about the relocation makes me think that there is a kind of dynamic allocator somewhere, which I don't like too much for a real time function like onProcess.
I will try to rearrange my code to make only one allocation at the beginning, by precomputing something like a buffer (I am rather sure that there will never be hundreds of messages received during one call to onProcess.
Thanks again
Benoit
-
sm_jamieson
- Member
- Posts: 551
- Contact:
I think the dynamic sized events is fundamental to the core of Usine, so I would think it is fairly well optimized - but still good to make code as efficient as possible !
Who is online
Users browsing this forum: No registered users and 5 guests
