30 May
2006
30 May
'06
4:46 a.m.
On Tue, 2006-05-30 at 09:04 +1000, Loki Davison wrote:
On 5/27/06, Patrick Stinson
<patrickkidd.lists(a)gmail.com> wrote:
Regarding gui/engine separation: This has occasionally been discussed
before, with various suggestions of how to use pipes to make it work
easily and consistently.
I came to think of, why not use the alsa midi layer? The engine listens
to a midi stream of commands which may be generated from a gui, or
perhaps coming from an external controller/sequencer. The gui could
listen to the same (external?) midi stream, showing you the current
state if you need it.
The advantage would be a consistent protocol for communicating between
gui and engine. The gui could be a piece of harware that you happen to
own. You could run headless and still have a full view of what is going
on. Many devolopers, as well as musicians, can recite this protocol
while they sleep, so no need to dig through source code to figure out
how the implementation is supposed to work.
Mmmm ... Perhaps one could even persuade the maintainers of Gtk/Glade to
implement a midi-controller-field, automagically doing the house keeping
and graphic updates?
Rosegarden already have a build in midi-controller construction kit,
which could be extended slightly to allow for buttons, sliders ...
anything ...
Or something similar in OSC. I am only advocating midi because, looking
at the landscape, there seems to be some consensus on that protocol.
--
mvh // Jens M Andreasen
Take a look at OSC. It assumes that all
computers' clocks are synced
via ntp, which is more than adequate to ensure its 64-bit fixed point
timestamps are accurate. This makes the programming easier and more
reliable, as you only have to program to your local clock. Relying on
an Ethernet LAN for heartbeat-style clock syncing is never a good
idea, as the MIDI specification describes (you don't see a Roland
keyboard assembling a TCP stack on its MIDI port, for example).
OSC does not define a transport, so you may use TCP or UDP or whatever
you want, as many others do. I highly recommend this as a solution for
you.
also a osc sequencer would be useful and yet another loop based midi
sequencer wouldn't be. I'd also recommend process seperation of gui
and engine. Then you can write the engine in something like c and the
gui in something like python.