[gmpi] Re: [OT] Re: Topic 7.1: Channel Formats / XML, Profiles

  • From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 9 Jun 2003 13:43:30 -0400 (EDT)

On Sat, 7 Jun 2003, Steve Harris wrote:

> On Sat, Jun 07, 2003 at 07:37:34 -0400, Angus F. Hewlett wrote:
> > For good usability in the Reaktor/AudioMulch/Bidule/Synthedit paradigm,
> > you definitely need multiple ports (aka channel groupings), and because of

> Can you expalin why? I use, and write plugins for, this type of
> architecture daily and I've never felt the need for enforced channel
> grouping. Grouping channels for presentation is another matter, but I
> definatly wouldn't want "if you have this channel connected you must also
> connect this one" type behaviour.

OK, "needs" is a bit strong, but I feel that it makes life much easier for
both the plugin developer and the end-user if we have a grouping system.

> BTW I've been using port to mean something different, but I think we're
> understanding each other.

By port (in the audio context) I mean a group of mono streams.

> > the relatively higher plugin counts and graph complexities, but at the
> > same time the smaller average size of the plugins, it becomes worthwhile
> > to consider optimised buffer formats (aka swizzling). It's a harder
> > problem to solve, but one I'd like to think is worth attempting.

> Do you have an example of a buffer layout that's more efficient than mono
> buffers?

Generally, mono is best.

> The only example weve seen so far is interleaving, which appears
> to be less efficient, though no-ones tested it AFAIK.

That varies on a case by case basis, and if someone has written a whole
suite of SSE-optimized smallscale modules for a modular GMPI environment,
it would be nice, although NOT essential, to be able to let those modules
talk in their native format.

Regards,
        Angus.


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 06-2003