30 May
2006
30 May
'06
3:47 p.m.
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:
I wrote a client-side OSC sequencer for supercollider.
check my site
for "scsynth".
On 5/29/06, Loki Davison <loki.davison(a)gmail.com> wrote:
On 5/27/06, Patrick Stinson
<patrickkidd.lists(a)gmail.com> wrote:
--
Patrick Kidd Stinson
http://www.patrickkidd.com/
http://pkaudio.sourceforge.net/
http://pksampler.sourceforge.net/
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.