[openbeosmediakit] Re: Common Plugin API for BeOS Audio

We should still support VST, but that ends very quickly if Steinberg
is not going to support us with VST3.

So, Andrea, can I count you in on the team and add you to our
discussion list ?

Frans.


-----Oorspronkelijk bericht-----
Van: openbeosmediakit-bounce@xxxxxxxxxxxxx
[mailto:openbeosmediakit-bounce@xxxxxxxxxxxxx]Namens Andrea Anzani
Verzonden: vrijdag 30 augustus 2002 11:28
Aan: openbeosmediakit@xxxxxxxxxxxxx
Onderwerp: [openbeosmediakit] Re: Common Plugin API for BeOS Audio



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: