Either way, the GUI runs completely independent from the audio processing, so it’s really a matter of what you need. Unless you have special requirements, I would use Supercollider’s Qt GUI.
Having your GUI as a seperate process has a couple of advantages, though. It forces you to think more about seperating GUI from “business logic” (see MVC architecture). Also, you might be able to run the GUI remotely on a seperate machine.
Thanks for your reply. A other advantage is that you don’t have to learn Qt GUI if you already have experience with FLTK, that’s the main reason I came up with this question. But yeah, Qt GUI might be a more logical choice and might have shorter development time / less code.
Network transmission on the local machine is very fast, ~= 0.1 ms.
(
var sendTime;
var addr = NetAddr.localAddr;
OSCdef(\get, { |msg, time|
"sent at %, received at %, took % seconds\n".postf(
sendTime, time, time - sendTime
);
}, '/test');
f = {
sendTime = SystemClock.seconds;
addr.sendMsg("/test");
};
)
f.value;
sent at 296.488050596, received at 296.48816946, took 0.00011886400000094 seconds
sent at 298.934210986, received at 298.934340414, took 0.00012942800003657 seconds
sent at 299.436209174, received at 299.43628224, took 7.3066000027211e-05 seconds
sent at 299.849523614, received at 299.84962019, took 9.6575999975812e-05 seconds
sent at 300.565279865, received at 300.565352342, took 7.2477000003346e-05 seconds
sent at 300.882368395, received at 300.882497228, took 0.00012883299996247 seconds
An external-process GUI should be pretty responsive.
Before Qt GUIs in SC, Linux and Windows users had to use SwingOSC for GUIs – a Java GUI server using an OSC interface. This was a bit sluggish, but I think the bottleneck was Java rather than the network protocol.