> On Thu, May 20, 2010 at 6:18 PM, Niels Mayer wrote:
>
> > I forgot to mention one of my main finds regarding clojure -- a nice Qt
> > interface, and working well w/ multithreaded...
> >
> >
http://tealeg.blogspot.com/2008/11/on-clojure-part-3-designer-uis-and.ht...
> >
http://briancarper.net/blog/clojure-qt4-system-tray-mail-checker
> >
> > As you'd expect from Clojure, the concurrency part of the app was a
> >> no-brainer. There are a bunch of threads hammering on a single global hash
> >> list of email messages, and they're all forcing updates of the GUI, but
> >> throw a bunch of dosync's around certain bits of code and it all works
> >> without worry. (Qt's invokeLater is also necessary if you're updating a Qt
> >> GUI from more than one thread at a time.)
> >
> >
> >> My first version of this app had even more threads, with one thread
> >> updating the GUI every few seconds, and another master thread managing all
> >> the mail threads. It also worked fine. It was overkill so I scaled it down,
> >> but it's really nice how you can coordinate a bunch of threads and don't
> >> have to worry about deadlocks and race conditions and whether your data
> >> structures are thread-safe.
> >
> >
> > Question: how easy is it to "add on" to an existing Qt/QtDesigner-based app
> > like, say, qtractor, the aforementioned clojure language extension?
> > (instead of "angelscript" mentioned in Rui's 0.1 whitepaper pdf... and
> > that's assuming the caveat mentioned in one of the above links "You must use
> > Qt Designer with the QtJambi plugins installed.") And how much would java be
> > able to "introspect" out of the C++/Qt-part of its environment without
> > having to be told about it. (e.g to access&manipulate, then schedule
> > rerendering of MIDI, timing, & non-destructive editing data.). The "slot"
> > stuff looks pretty introspective inter-call between QtDesigner and clojure
> > (from first link):
> >
>
> i think you're missing the model/view separation that apps like qtractor (or
> ardour) have. added access to the GUI elements is relatively easy because
> they are semantically simple objects. providing access to the "model" (e.g.
> the MIDI data) is quite complex.
>
> just for reference, torben wrapped libardour in python and ended up with a
> 500MB library. he was able to load and play an ardour session entirely in