20 May
2010
20 May
'10
9:20 p.m.
On 05/20/2010 08:39 PM, Nathanael Anderson wrote:
Cons: Uses a pre-compiler for generating
"signal/slot" connections,
Several of the core classes (like QString) will spread virally through
your code. Because it's a full framework, it sometimes doesn't mix
well (e.g. if you write LV2 plugins based on Qt, as I have, you may
uncover some strange bugs).
As the gui is only used for configuring options, and not interaction
while the program is running (a restart is fine in this use case) I'm
leaning to a basic c/c++ daemon with osc i/o (udp, non blocking, brain
dead easy to use :) ) to communicate with a front end . . . which also
lets me focus more on fast tracking features into the backend, and at
lease initially just putting a hacky gui together, with very loose
coupling between the 2. I know sooperlooper and linuxsampler both
support modes of operation like this. Any dev's here implement a loosely
decoupled frontend/backed like this before and run into issues i with it?
Well, this is a bit different, but I made an osc server with liblo in Jackbeat,
and got no obscure issue IIRC.
But I sense that you are a bit afraid about dealing with multiple threads.
And in what you explain you'll still need an OSC thread in your daemon, which is
waiting for OSC messages and dispatches them when they arrive. So you'll have to
implement some kind of (IPC) communication channel between this thread and your
RT thread. GUI or not, you have to deal with this ;-)
Now, because you have an RT thread, there are some traditional IPC approaches
that you can't use here. You can't do any blocking calls in the RT thread, so
the usual mutex/lock-based IPC is not ok.
What I do in this situation is sending messages from one thread to the other
through a jack ringbuffer. This is 100% realtime-safe.
--
Olivier