[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] CocoaBridge bug
probably, because since Ryan's excellent CocoaCollider < http://
there wasn't any further development of the CocoaBridge.
I know CocoaCollider, it is very nice i agree, but i do not use it.
Full binding is nice if you use extensively ObjC, but <humble
opinion> it has also an overhead. I tend to prefer the light approach
of CocoaBridge for managing small additions to sc using Objc/Cocoa :
it is effective and the invocation mechanism is the same.
should be removed.
I understand perfectly from the CocoaCollider point of view. Ryan's
work is the perfect addition for using a full-option Cocoa with SC.
But, <still a personal user view>, i don't want to have two
applications for one purpose. SuperCollider development is constantly
changing. I prefer to have one application.
For exemple, if i want to draw an NSImage with SuperCollider, i will
prefer CocoaBridge, i won't use CocoaCollider for a simple addition.
(or i can choose SwingOSC wich offers also a java alternative for
GUIs and do not need to have a 'different' sc application). As a
second exemple, for testing for small projects i modified the
CocoaBridge, so it can accept Class methods and do simple automatic
conversions (along with the doesNotUnderstand method in sc you can
create nice Proxies) and i still had a light and transparent approach
that suited my needs...But of course that's my point of view.
I do not know if you fully understand me but i really think
CocoaBridge is a very nice alternative, wich keeps the transparent/
decoupled aspect of distributed/remote messaging.
Thanks a lot for your response and attention Jan