17 Feb
2013
17 Feb
'13
11:10 p.m.
On Sun, Feb 17, 2013 at 4:45 PM, Harry van Haaren <harryhaaren(a)gmail.com> wrote:
On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <pcoccoli(a)gmail.com> wrote:
The only reason you need this is because you memcpy the object.
You're effectively serializing your object and passing them over the
ringbuffer. If you do it this way, you should at least consider
explicitly embedding the type and length as the first member of
EventBase (and have each derived class set their own type and length
in their constructors), and reading those before touching the object
you read.
JACK ringbuffers are
ideally suited to passing simple types (like floats), and not vairable
sized things (like different derived Event classes). Your enum for
event types is a bit of a red flag, too. While its perfectly valid,
"type flags" like this more often than not accompany inflexible,
tightly coupled code (which may be fine in a small audio app, but few
apps stay small).
Apologies, forgot this section:
Yes indeed all "Event" types will be contained in a single enum, and hence
adding / removing
events will cause a recompile. While unfortunate, I don't know how to go
about making this
cleaner. #define's anybody?