[openbeosmediakit] Re: Common Plugin API for BeOS Audio

  • From: Andrea Anzani <oxygenum@xxxxxxxxxx>
  • To: openbeosmediakit@xxxxxxxxxxxxx
  • Date: Fri, 30 Aug 2002 09:27:33 +0000

I don't think the MediaNode system in BeOS is good for this purpose.
The MediaNodes are good for inter-program works; I think Frans is looking
for an intra-program system to process sound busses.
We have a VST wrapper, but try to load and link ten addons out of a 
MediaPlayer, and then try to load these VSTs out from SoundPlay.
With MediaNodes you have >10 threads with SoundPlay only one.

RealtimeFX is a good idea, but i think that beos should also support 
the universal standards of the computer music world.


On 2002-08-29 at 20:31:37 [+0000], you wrote:
> Hi Frans (and everyone else)...
> I've given the same issue a lot of thought - I absolutely (100%) 
> believe the right
> path here is to use the MediaNode facilities provided by the mediakit. 
> The reasons for this are numerous 
> - Part of the OS - integrated.
> - Access to plugins from a variety of formats via wrappers (VST etc)
> - Connection/management facilities through the media roster
> - Format agnostic
> - Controls published via ParameterWeb
> - Offline and realtime runmodes
> etc
> One of the main issues with the media kit is the fact that the 
> groundwork is there, but
> there are relatively few niceties as you get in the rest of BeOS - in 
> this context, what 
> you are proposing is basically a convenience class for nodes 
> specifically dealing with 
> audio data. I've written a very basic 'AudioFilter' class myself, 
> although its probably
> not suitable for release.
> AddOns are already quite easy to load in BeOS - although an 'easy' 
> application-managed media=5Faddon=5Fserver (based on Cortex AddOnHost 
> perhaps=3F) 
> would certainly be something to look at.
> If you are setting up a list, I am very keen to discuss this - I think 
> a few well 
> documented nodes of this type could really help kickstart media 
> development.
> I don't want to see a separate standard emerge outside of the existing 
> structure -
> if there is something lacking in the media system as it is now, we 
> should certainly
> expand and improve (I'm happy to discuss these ideas too, although a 
> lot is probably 
> GlassElevator territory...)
> btw re : VSTi - this is something we can create a wrapper for, as 
> mentioned above.
> David Shipman

Other related posts: