[gst-devel] volume plugin with dparams

[Erik Walthinsen]

On Wed, 14 Nov 2001, Karsten N . Strand wrote:

> I'm currently looking into gstreamer as the platform for my new digital
> audio mixing system project, and have a few questions. The plans for the
> mixer is to build a external control board with sliders, aux buttons, and
> two "turntables" (for scratching, searching and looking cool), using a
> board with a bunch of adc's and a philips P89C51RC+ controller chip. The
> control board will have a serial interface. This step is pretty
> straightforward, with some kindly given soldering help from my father.

Very cool.  I've been thinking about the hardware design of something like
that for quite a while.  I want to make sure it's a fully automated board,
though.  Easiest would be the buttons, which would be keyboard-style
momentary tactile buttons, with an LED for status (preferably the button
itself would be translucent...).

The sliders would be motorized somehow, I'm thinking of either using a
regular fader with a motor and a belt, or using a rotary encoder and
motor, just using a slider body and not a variable resistor.  Using a
variable resistor fader would be cheaper, but potentially less accurate.
An optical rotary encoder of that size and resolution could be expensive.

As for knobs, I've thought of putting a ring of LEDs around the thing like
all the manufacturers do, but realized that it sucks.  Someone pointed out
to me that you don't need fine-grained display of the knob position,
because it just doesn't really matter.  You just need a high-resolution
sensor.  Well, that's fine, but LEDs around a knob body must be viewed
from the *top* down, which doesn't cut it.  So I'm thinking of some
mechanism using a rotary encoder and a small stepper motor.  Question is
whether the stepper resolution can be enough, though it's back to the
argument that where the knob visually is isn't as critical.  That means a
low-res stepper would work just fine, as long as the system resets the
precise origin of the knob relative to the rotary encoder each time.

As for the electronics, I'd use Microchip PIC's for each control group on
a I2C bus, with some kind of main controller.  I'm liking the SitePlayer
(www.siteplayer.com), because it's $30 and has ethernet.  Problem is that
it only has a single SPI port, and isn't all that fast.  But heck, it's
ethernet <g>

> The next step is to hook all these controls up to actual mixing software,
> and this is were I thought maybe gstreamer could be The choice. I have been
> following the project for a while, and I really think it's the future for
> streaming media in linux (the gtk/gnome world anyway, it seems like the
> qt/kde people have somewhat settled for arts). Well, anyway, that's my
> story.. Here's the questions:
>
> Is anyone working on adding dparams to volume?
I think the current volenv element is what you want, since that was one
of the test elements (iirc) for dparams.  I'm still a little fuzzy on
dparams myself, esp in the context of a live application.  steveb, you
have any comments?

> Are the latency numbers good?
As long as the input and output devices are good, yes.  The plugins can
introduce latency, but I don't think any of the raw audio ones do.  The
cothread switch time is constant and quite small (<1000 cycles per switch,
probably a lot less).  Any threaded pipeline with queues and such will of
course add relatively unpredictable latency, so you just don't do that <g>

> Any work on some kind of sequencer to record stream changes and dparam
> values?
Can you elaborate a little more on what you mean by this?

> Any plans for a terminatorX-like* element for gstreamer? terminatorX (
> http://terminatorx.cx ) is a kickass virtual turntable app for linux, but
> you probably knew that anyway :)
Hmm, I have no idea what it actually does.  I guess the question is what
precisely would the element do?  I would guess that it takes some kind of
data pointer and uses it to output samples from an, um, sample, doing
various interpolation and stuff.  That would mean it would have to load in
the whole sample up front, which would be interesting.  It could handle
demand-loading by seeking to the appropriate places in the file.  However,
if you want to display a peakgraph, you'll have to load them all anyway,
probably either up-front or via a smart tee.  A peakgraph element needs to
be written, along with a really good waveform display widget for gtk....

> I would very much like to help with any of these issues, as they're all
> vital to my application, but I'm no wizard, so it might take some time to
> me to understand gstreamer's architecture and api completely. I've never
> had any experience with GObjects (just basic gtk+) before, and I think the
> official docs is pretty sparse at this moment, so I would be grateful for
> pointers to good alternative documentation.
Unfortunately, the docs on gtk.org are about it, besides the source, which
is of course always canonical.  The API freeze is in place, so the docs
should soon match the source, but API docs aren't quite enough usually ;-(
It took me several tries to start effectively using GtkObject, so....

> If anything useful come out of the mixer project, I will (oh'course)
> release the code and schematics under lgpl, gpl. And then, maybe someone
> else will want to be a part of the project too, and we will take over the
> evil music industry together, and ride happy into the sunset :)
Sounds good!  If you want to collaborate on hardware design, let me know
and I'll start preparing to build stuff (i.e. clean my room <g>, acquire
some hardware and devel kits, etc.).  If we can do an open-source control
surface, that'd be very cool <g>

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_