Hi, Do you mean that you are sending one packet after 256 notes have played? In that case, I assume you are using it to periodically re-synchronize independant clocks. If that's the case, the local computer should be used to generate the MIDI clock according to its own clock. The local computer's own clock can then by re-synchronized periodically with the remote computer, which will automatically also re-sync the local MIDI clock signal. Does that make sense? Am I correct in understanding that MIDI is not being sent over the TCP connection? Steve On 5/26/06, krampenschiesser(a)freenet.de <krampenschiesser(a)freenet.de> 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. On 5/26/06, krampenschiesser(a)freenet.de <krampenschiesser(a)freenet.de> wrote: -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/

On Tue, 2006-05-30 at 09:04 +1000, Loki Davison 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

It is a good idea, as long as your interface is relatively simple... but what about when you want to do something that is sort of custom to your interface, like for example showing the waveform on the screen by sending peak or spectrum data. you'll end up having to create a mini "custom" protocol over MIDI using your own SysEx messages or something, so you may as well keep it simple and use pipes.. However, yes, for very simple interfaces, like a few knobs and sliders, it does make sense to use MIDI this way. You'd be building a "controller" for your realtime synth process, for example, which is exactly analagous to using an external controller for a hardware synth. Steve On 5/30/06, Patrick Stinson <patrickkidd.lists(a)gmail.com> wrote: