[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
Hi,
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.
Andrea.
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:
