Re: audio-specific UI component libraries for Cocoa?
Re: audio-specific UI component libraries for Cocoa?
- Subject: Re: audio-specific UI component libraries for Cocoa?
- From: Justin Carlson <email@hidden>
- Date: Mon, 1 Nov 2010 17:44:59 -0400
> Kevin Dixon wrote:
>
> I was wondering if there are any UI component libraries for audio
> controls available for Cocoa? The standard UI components (NS* family)
> have some short comings when it comes to dealing with audio. Some
> specific things I find myself needing: logrithimic sliders, circular
> sliders that behave like Logic (e.g. you don't have to move the mouse
> in a circle), or text fields that respond to dragging.
> I can write these things of course, but I don't have the time.
there are other libraries, but not much is available that is *really* specific to your request (that i am aware of). here are some that come to mind:
AUGUI Framework:
http://augui.sourceforge.net/
VSTGUI:
http://sourceforge.net/projects/vstgui/
WDL:
http://www.cockos.com/wdl/index.php
> Well, if I come up with anything I'll LGPL em'
there are some important things to consider when providing a shared objective-c framework for this purpose. you'll either:
1) install it in a standard location
-or-
2) use a few build and/or runtime tricks to ensure each plugin is using a copy of every exported objective-c class - which would have a unique name, such as: MAUWidget$(AUMANU)$(AUTYPE)$(PLUGIN)LogSlider
the problem with the first means that there would be no guarantee to the developer that the framework would remain the same over time because other plugin distributions may install a newer version of the framework (potentially, with what is their own branch of the framework). there would be an additional danger if anyone ever installed a copy in a private location (such as their component's bundle). you could also fake this with private objc classes and a version scheme:
- [MAUView initWithRect:(NSRect)rect auFrameworkVersion:(unsigned)version /* used to specify which subclass instance to return */;
the problem with the second option is that every plugin would (by default) export every objc symbol (and their dependent symbols). this means that every exported plugin used by a host would load several (redundant) widget/control/view classes - each having different classnames.
there are a few ways around this, but none are particularly fast to implement. personally, i'd opt for a naming scheme similar to the second, and put whatever implementation i could in c++ (imagine wrapping/rewriting a good chunk of NSView->NSObject and putting that into the implementation of the c++ class implementation used by the NSView subclass) because you can't (easily, safely, or reliably) reuse objc symbols.
anyhow - there are many other approaches one could take to tackle this problem.
good luck!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden