>
> 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?
Nathanael
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri May 21 00:15:02 2010
This archive was generated by hypermail 2.1.8 : Fri May 21 2010 - 00:15:02 EEST