[linux-audio-dev] Re: Midi Clock

Jens M Andreasen jens.andreasen at chello.se
Tue May 30 06:46:20 UTC 2006


On Tue, 2006-05-30 at 09:04 +1000, Loki Davison wrote:
> On 5/27/06, Patrick Stinson <patrickkidd.lists at gmail.com> wrote:
> > 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.

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




More information about the Linux-audio-dev mailing list