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: Kevin Dixon <email@hidden>
- Date: Mon, 1 Nov 2010 18:00:52 -0700
I'm not sure I understand the Cocoa namespace problem very well. Does
this mean that even if the controls are distributed as just .h/.m
files to include in your project, the names could conflict if multiple
plugins simply have the same class name? Maybe I'm not remembering
correctly, but we *do not* have this problem in C and C++, correct?
This seems a bizarre design choice.
I notice that AUGUI is for Carbon, which I'm not developing for. I'll
take a look at VSTGUI and WDL. Thanks
-Kevin
On Mon, Nov 1, 2010 at 2:44 PM, Justin Carlson
<email@hidden> wrote:
>
>> 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
>
_______________________________________________
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