[gmpi] Re: Item 0: Agenda

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 12 Feb 2003 14:15:30 -0800

Hmmm. I'd really hate to see things start out with 24-bit integers as an acceptable audio representation :P

I agree. It was just an example, not suggested as a baseline.



Can we finally just pick *one* PCM audio representation (32-bit float, perhaps) and stick with it?

32-bit float is the obvious current favorite, but what about the future? Seems that only by decoupling the specific data formats from the architecture can we achieve a long-range stable solution.



Also, since we're considering generalities, aren't there other kinds of things a plug-in can transmit besides audio and MIDI (strings, perhaps)?

I agree. This is why I think all plug inputs and outputs should be typed. Audio (with format subtypes) and MIDI (maybe with subtypes too, who knows?) types would be defined initially, of course with really tight audio-specific and MIDI-specific implementations basically ala current plug formats. More types could come later if the community deems it desirable/necessary. Maybe we could define generalized control types too, e.g. let plugs have a "GUI Event" input to receive event messages routed through the plug-in framework as opposed to making the host turn GUI events into SetParam() API calls. With typed pins as part of the basic architecture, we get the freedom to add whatever else we may discover we need in future.



In this light, MP3 is just another kind of non-audio data. MP3 frames are something that can be passed between ports of type "MP3 Frame", distinct from MIDI or "audio" or anything else...

I agree. I was merely stating the obvious -- for a plug that does audio processing, an MP3 input has an inherently different blocksize from whatever other PCM audio streams the host may be processing with plugs, so there's a perhaps nontrivial timing/resynchronization complication there for the host to deal with. Not to mention making it more complicated/bursty to seek to a desired sample frame, since you have to decode the whole MP3 frame first.


This brings up a scope question: In a pro sequencer or DAW, (or DJ-ish app too, I guess, or even a toolkit system like Max/MSP), why would a plug ever have to process an MP3 frame? Don't all the apps convert to their fave PCM format upon importing an MP3? Or is GMPI supposed to work for end-consumer apps like WinAmp plugs too, where consumption formats like MP3 are a more natural thing?

-- Chris



Regards, -Amar

Amar Chaudhary, PhD
Creative Advanced Technology Center
1500 Green Hills Road
Scotts Valley, CA 95066
amar@xxxxxxxxxxxxxxxx



Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
Sent by: gmpi-bounce@xxxxxxxxxxxxx

02/12/2003 01:34 PM
Please respond to gmpi To: gmpi@xxxxxxxxxxxxx
cc: Subject: [gmpi] Re: Item 0: Agenda




Could we perhaps handle this in the agenda by simply saying we need
to consider whether plug inputs and outputs should be typed at a
finer level than just whether they're audio or MIDI?  I.e.
audio/24-bit linear, audio/32-bit float, audio/MP3, etc.  (I have
some ideas to contribute for this once we get to the solutions stage.)

BTW, what would MP3 really mean in terms of a plug-in input?... What
would a buffer be?  I guess one MP3 frame?  Whose size would almost
always be different from linear audio blocksizes...?

-- Chris


P.S. If anyone has collected URLs for non-NDA tech info on all the existing plug-in formats, could that be posted here? Maybe we can also put that on the list home page?


I disagree - for instance, if you want to apply a chain of phase vocoder
plugins, you don't want to convert to and from the frequency domain for
every plugin. I have a large number of plugins in MN that are completely
reliant on this facility.

I'm only arguing this should be on the agenda so we can agree to throw it
out later. ;-)

... And we're going to come up against the viciousness of pluggable data
types when we talk about event data anyway!
>
--Richard

-----Original Message-----
From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx]On
Behalf Of Mikael Hillborg
Sent: 12 February 2003 20:27
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: Item 0: Agenda


I'd say things like the phase vocoder and MP3 are one layer above the plugin architecture and its framework (and there are *lots* of things like these). So I'd suggest to leave it or we'll never get a useful spec developed. ;-)
 >
 >/MH
 >
 >>  -----Original Message-----
 >>  From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx]On
 >>  Behalf Of Richard Furse
 >>  Sent: den 12 februari 2003 21:20
 >>  To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: Item 0: Agenda


In audio packaging (4), we might want to discuss other schemes such as
MP3,
  phase vocoder etc. And even pluggable formats - I use these heavily in my
  own softsynth environment and couldn't release my modules as plugins
  without. (BTW did anyone ever read that LADMEA stuff - this has a thorough
  handling of these issues?)

I'm suspecting this will be thrown out as over-complicated, but it
probably
should be on the agenda.

--Richard


---------------------------------------------------------------------- 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

---------------------------------------------------------------------- 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


---------------------------------------------------------------------- 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


----------------------------------------------------------------------
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


----------------------------------------------------------------------
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: