Re: [linux-audio-dev] App intercomunication issues, some views.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Phil Kerr (phil_AT_plus24.com)
Date: Thu Jul 25 2002 - 02:24:56 EEST


Hi all,

> I've been meaning for some time to make a universal transport control, a
> separate app whose sole purpose would be transport control.
> This would be rad (TM) for a number of reasons:
>
> 1) Get your whole rig to start at once, even if you're not using
> ecasound or ardour

Which is precisely why I wrote DMIDI.

The dmidid server binds the network to the MIDI hardware (though OSS or
ALSA). A note on/off or start/stop from a MIDI device or controller app is
broadcast over the subnet and picked up by any DMIDI client listening. It
checks to see if it's for this node (or if it's a broadcast message) and then
passes it on to whatever.

Timing is event driven and latency is kept low by running everything
SCHED_FIFO. The only change to raw MIDI protocol is the addition of a 4
byte header for node identification which is stripped before it's passed to
the MIDI layer. It's now got apps running on Linux and Palm and once I've
tested some of the new QT code which is using native QT socket calls and I
should have applications running on Linux, Palm, Mac and Windows. If I get
time (sigh) I'll look into the possibility of a VST plugin.

It's a very simple protocol to use and it seems to work fine on a LAN. It
can also handle the saving and restoring of app config data by broadcasting
it's config as XML.

MIDI is different to audio and it seems wrong to lump it in with Jack as it's
just adding complexity. Being able to sync things up with Jack would be
good.

If it goes into ALSA then let's think about being able to use it from other
platforms. Being able to show to the wider music community that Linux, once
again, is the perfect tool for bringing things together..... because it's
open.

Cheers

Phil

Kai Vehmanen wrote:

> On Wed, 24 Jul 2002, Andy Wingo wrote:
>
> [JACK transport control]
> > I've been meaning for some time to make a universal transport control, a
> > separate app whose sole purpose would be transport control.
> > This would be rad (TM) for a number of reasons:
> >
> > 1) Get your whole rig to start at once, even if you're not using
> > ecasound or ardour
>
> Yup, I agree, a generic (and simple) transport master client would be a
> very valuable addition. Even though "works out-of-the-box" is a very high
> priority item in ecasound development, I must admit that achieving this
> goal is anything but easy with applications of this size. If nothing else,
> broken soundcard hardware, kernel drivers (and sometime the kernel itself)
> and libraries make it practically impossible to prepare for all
> situations. And the last thing people developing new client apps need is
> to worry about bugs and misc problems of other large client apps.
>
> In other words there should be enough jack_simple_client style apps to
> cover all JACK functionality. Getting these apps to work should require no
> more effort than that required by jackd. This is critical for getting more
> developers writing JACK clients. Requiring installation and use of
> ardour/ecasound/someotherbigapp is not good.
>
> > 3) funny tricks with beats -- speed up, slow down the tempo. Loop the
> > last 4 beats. All the GDAM tricks, but on a system-wide level.*
> [...]
> > * You'll run into some buffering issues here when streaming from disk.
> > Oh well.
>
> Actually the JACK transport API is quite flexible in this way. Ecasound
> doesn't yet (if ever, ecasound prefers per-audio-object looping to
> session-level looping) support the loop transport mode, but it does
> support "live seeks" (ie. random-access style changes in transport
> position during successive callbacks). If the disk-i/o subsystem can't
> keep up with the changes, the rt-part (callbacks) will ignore it until
> it has caught up.
>
> Of course for sample-accurate looping, the looping transport mode is still
> the only real solution. It's also true that transport-change patterns
> involving regulars jumps (like skipping x samples during each callback)
> will cause trouble to clients with slow non-rt i/o subsystems.
>
> But anyways, the most important feature IMHO is the basic transport
> control (ie. start, stop and non- or near-rt fw, rw and setpos). Most
> importantly this solves the old LAAGA use-case with
> drum-machine+soft-synth+multitracker (<http://eca.cx/laaga>).
>
> --
> http://www.eca.cx
> Audio software for Linux!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jul 25 2002 - 02:48:35 EEST