Excerpts from Arnout Engelen's message of 2010-05-20 16:19:01 +0200: It seems like lua is a good choice when you need to interface with C, but for some reason I can't name a single project that uses lua for the GUI. -- Regards, Philipp

On Thu, 20 May 2010, Charles Fleche wrote: When I released the Composite Sampler, I had to solve two tricky bugs: 1. zynjacku's UI would freeze when loading it. Cause: Glib event loop initialization and PyGtk. Fix: zynjacku now initializes the Glib event loop, but this comes with some other undesirable side-effects. 2. Ingen would crash at exit if you loaded the Composite plugin, and then unloaded it. Cause: When Qt initialized thread-local storage, it made an assumption that QtCore would only be unloaded at application exit. Fix: Qt's trunk has a fix to clean up TLS when the library is unloaded. I don't think it was backported to older release branches.[1] Anyway, Qt is a large framework for cross-platform application development (and very good at that). So, when you use its core library (QString, QThread, etc.) in new and non-standard ways (LV2 plugins) you're liable to find bugs that violate the assumption: "This is a Qt application." :-) hth, gabriel [1] http://bugreports.qt.nokia.com/browse/QTBUG-9436

On Thu, 20 May 2010, Chris Cannam wrote: Not yet. It doesn't have an LV2 GUI, yet. But the core logic of the plugin is still using QtCore (QString, QThread, QMutex, etc.). That works fine, except for the issues I mentioned above. -gabriel

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.html http://briancarper.net/blog/clojure-qt4-system-tray-mail-checker As you'd expect from Clojure, the concurrency part of the app was a 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): (gen-and-load-class "foo.gen.Slot" :methods [["slot" [] Void]]) (ns foo (:import (foo Ui_MainWindow)) (:import (com.trolltech.qt.gui QApplication QMainWindow)) (:import (com.trolltech.qt.core QCoreApplication)) (:import (foo.gen Slot))) (def slots (proxy [Slot] [] (slot [] (prn "Slot Called")))) (defn init [] (QApplication/initialize (make-array String 0))) (defn exec [] (QApplication/exec)) (defmacro qt4 [& rest] `(do (try (init) (catch RuntimeException e# (println e#))) ~@rest (exec))) (def Foo-main (fn [& args] (qt4 (let [ui_main (new Ui_MainWindow) mainWindow (new QMainWindow)] (. ui_main (setupUi mainWindow)) (let [pushButton (. ui_main pushButton)] (.. pushButton clicked (connect slots "slot()"))) (. mainWindow (show)))))) Niels http://nielsmayer.com

On Thu, May 20, 2010 at 06:46:16PM -0400, Paul Davis wrote: this was a COMPLETE wrapping of everything. and most of the stuff were REALLY large boost::python symbol names. i could have probably gotten the size a lot smaller -- torben Hohn

On Fri, May 21, 2010 at 8:33 AM, torbenh <torbenh(a)gmx.de> wrote: Java is open source. There are people using embedded and sometimes RT java, to varying degrees of effectiveness, in all sorts of everyday devices, like your cable company-provided DVR and set top box (which I've worked on) and sometimes even your credit card verification devices (which i've also worked on). There's also gcj, and OpenJDK, with a relatively up-to-date JIT available and distributed with major distros like Fedora. java-1.6.0-openjdk.x86_64 1:1.6.0.0-38.b18.fc12 @updates gcc-java-4.4.2-7.fc12.x86_64 : Java support for GCC hmm... maybe this actually works. still relies on some particular jvm. effectivily throwing away the whole portability mumbojumbo. No the JVM is open sourced, the language is a standard, there's a good chance someone has done it, either as product or open-source. Remember that embedded Java (sometimes realtime) and embedded Unix form the core of many handheld devices, set-top boxes and there's more of those than there are linux-using musicians and audio professionals. No! Did I actually say that, no.... To elaborate: I'm glad all those libraries have strong-typed APIs, and that they were written with technology that'll self-check against major API mismatches, which is helpful to prevent unnoticed bit-rot in applications and their dependent libraries and APIs. However programming in those languages, prototyping UI's in those languages is really tedious. Changing and updating and adapting applications for new uses is very frustrating in those environments. Not true, hasn't been true for a long time -- some of the earliest common lisp compilation triumphs were showing that a few carefully declared typed variables can make Lisp as fast as Fortran. Today: http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf "How to make Lisp go faster than C" and i really find bigger programs pretty confusing in dynamic languages That's just because the programmer wasn't fastidious enough in naming variables or structuring the program. You can program badly in any language. Often dynamic language "programs" often started as a simple script that grew... Every program needs refactoring eventually. To each his own... Did I even mention perl? Blech. I was suggesting Clojure and Groovy, for their readability/elegance/simplicity/ease-of-use and ability to reuse all of Java classes, JVM advances, portability, wide-adoption, security, etc. i really dont see any advantage over faust here. Actually, my thoughts during the faust presentation @LAC2010 indicates we seem to inhabit different islands each with it's own cargo-cult... (07:59:14 AM) npm: Q: what's the difference or motivation for this Block (07:59:58 AM) herman_mixer: Someone in the audience who can relay from IRC? (08:01:38 AM) npm: well i guess that answers the q (08:01:58 AM) npm: although i'd say 1950's not 1970's (08:03:40 AM) npm: http://en.wikipedia.org/wiki/Lambda_calculus --> (08:03:58 AM) npm: 1936 Church's work was the inspiration for the development of Lisp as a language. The "able to parallelize any valid faust code" is a fundamental corollary to functional programming and forms the basis of numerous implementations: http://en.wikipedia.org/wiki/Concurrent_computing (somebody should add Faust as it's not there, clojure and scala are, and are also much more widely known). Clojure, is the next step past that, as it directly integrates language structures enabling parallelism, along with the functional style needed to make it all work: http://clojure.org/agents And for the things that people do in C or Faust, that's exactly what they should continue doing. However, it is simply bad architecture to muddle up RT code with arbitrary UI code. It's much better to setup a simple network protocol so that the RT code only need listen on a socket for any I/O related to changing it's state. Which sounds like exactly the path taken with OSC control of plugins, etc: http://dssi.sourceforge.net/why-use.html "DSSI separates the plugin and user interface, using standard Open Sound Control (OSC) messages to communicate between them. This ensures that the plugin's controls are consistently externally available, provides a guarantee of automatability, and encourages clean plugin structure." And then just write an external UI program that talks OSC and attempts to keep up as best possible with the realtime processing going on in a different process. Allowing that realtime process to determine scheduling and receipt of UI events. Why muddle-up perfectly good realtime code w/ a bunch of GUI? and angelscript would be a valid interpreted language. because it gives the Interesting. I was thinking, initially, more of a language to do what Cakewalk did with "CAL" http://www.bikexprt.com/calfiles/index.htm except you'd use modern implementation of their primitive lisp for MIDI event processing. 2 years is like 10 in internet time. But that's what I do! Looks like I won't have to dream long: http://github.com/rosejn/midi-clj http://github.com/rosejn/osc-clj http://bitbucket.org/amb/clojure-snippets/src/tip/audio.clj http://github.com/amb/rezo http://osdir.com/ml/clojure/2010-01/msg00900.html (defn osc-recv "Receive a single message on an osc path (node) with an optional timeout." [peer path & [timeout]] (let [p (promise)] (osc-handle peer path (fn [msg] (deliver p msg) (osc-remove-handler))) (let [res (try (if timeout (.get (future @p) timeout TimeUnit/MILLISECONDS) @p) (catch TimeoutException t nil))] res))) I bet the above would combine quite nicely with a http://qtjambi.sourceforge.net/ GUI via Clojure.... -- Niels http://nielsmayer.com

On Fri, May 21, 2010 at 11:53 AM, Chris Cannam <cannam(a)all-day-breakfast.com> wrote: Yes. And what motivated Faust when other approaches offering similar ideas existed. Because, for example, a lot of the work on macros revisits issues solved in common lisp's macro system. Continuing from #lac2010: .............. (08:31:53 AM) npm: sounds like the common lisp macro system: http://en.wikipedia.org/wiki/Common_Lisp#Variable_capture_and_shadowing (08:34:41 AM) sampo_v2: sure. this is term rewriting for faust (08:37:30 AM) npm: but the ideas are the same -- the only diff is where the parantheses are (08:41:39 AM) npm: clapclapclap (08:47:05 AM) torbenh4: and that faust is by some magnitude faster than almost anything else. (08:47:18 AM) torbenh4: except C++ :> ............. At the same time, who can argue with working C/C++ code. For example, I use your code all the time. Chris, and I'm very thankful it's in pure C/C++ (and it's very awesome and fast... results so far... using a combination of vamp-plugins, groovy&apache-velocity&javascript&flash via xwiki java-based platform http://nielsmayer.com/ts-episode-timeline.png http://nielsmayer.com/ts-episode-evnt-anls.png ). .... N.b: Seen in http://frinika.appspot.com/ readme: java -Xmx256m -Xincgc -jar frinika.jar java -jar -Xmx512m -XX:+UseParNewGC frinika.jar (please report if you find this helps). For jack using java 1.6 you need to add -Xss20m to increase the stack size ... -- Niels http://nielsmayer.com

On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote: Well, indeed a big part of the Sun JVM has been open-sourced under the name 'OpenJDK'. That does not mean the Java RTS is open-sourced - I'm pretty sure it isn't. But I'm not even sure RTS provides the kind of RT we're looking for in the LAD world. What kind of 'real time' are we talking about here, exactly? I think the definition relevant for the LAD world is basically: "it can be guaranteed that no non-RT-safe calls (like anything that may block, including malloc) will take place while handling the JACK process() callback". Can OpenJDK provide that guarantee? This never has been quite clear to me. The JACK thread can be run at a higher priority than the other Java process threads (including the GC thread), so as long as there's no non-RT-safe calls I think we should be safe from being interrupted by the GC (right?). Probably the jack process() callback would call some Java code though JNI (like JJack[1] does). *If* JNI doesn't do anything non-RT-safe, and *if* it is possible to avoid doing non-RT-safe stuff at the Java side (by adhering to some rules in your Java code, much like you'll have to do when writing C code), it'd be possible to write RT-safe code in Java. It sounds possible, but there are some big 'ifs' there. Of course the more interesting features of Java would probably still be forbidden to be used in the JACK process() callback. I tend to disagree: actually I find changing/updating/adapting things in a dynamic language is more frustrating and tedious because there's no compiler to tell me which bits I missed. But perhaps we shouldn't rehash the old static vs dynamic typing debate here ;). I'd say you can ask the same question for any functional language. Other representations are useful to make the algorithms in a given field easier to read, write and/or manipulate. Arnout [1] http://jjack.berlios.de/

On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote: sure. i have never liked lisp like languages. but my main feeling about them, is that you need to write too much. which seems to be the contrary of how you are arguing. no you didnt mention perl. but perl is often hailed for being so concise. the reason why dssi does this is not that things would muddle up. its a workaround for the "Qt and gtk+ dont really work in a single process" problem. i dont see why "implementing 2 things in the same language" muddles anything up. i admit that it does enforce not muddling it up. but basically you end up with 2 layers of marshalling. one layer for the marshalling from normal thread to the RT thread. and another for the osc marshalling. i consider cpu time pretty precious in RT contexts. GUIs get pretty sluggish, once the DSP load hits 50% and this kind of marshalling/copying data around doesnt help at all. hmm... its probably a matter of taste. but i find the equivalen c++ easier to read. assuming we have a proper modern c++ osc lib: boost::unique_future<OscMsg> osc_recv (OscPeer peer, std::string path) { boost::shared_ptr< boost::promise<OscMsg> > spromise( new boost::promise<OscMsg> ) peer.add_handler( path, [=]( OscMsg msg ) { spromise->set_value( msg ); peer->remove_handler( path ); } ); return spromise->get_future(); } main() { auto msg = osc_recv( peer, "bla" ); try { msg.timed_wait( 1000 ); cout << msg.get(); } catch { cout << "didnt work"; } } -- torben Hohn

On Sun, May 23, 2010 at 8:44 PM, Chris Cannam &lt;cannam(a)all-day-breakfast.com&gt; wrote: ... by which I don't mean to imply that I can't understand it (although, with C++, there is always the possibility that I _think_ I can understand it but am sadly mistaken because of some weird shit happening behind the scenes). I just mean that I can't simply read it. This may be one really serious advantage for the everything-in-C types -- a competent C programmer can understand any C, whereas C++ is big enough to have many different "schools of C++" which are mutually unintelligible without further study. That's also the seed of its popularity, I suppose -- everyone can write the way they like in it, and if you can't work out how to do it properly, you can always drop back into C. Chris

On 05/23/10 17:14, Olivier Guilyardi wrote: You can assume quite a bit, if you are willing to assume something that could be wrong. ;) If that doesn't work as expected, then whoever over-rode operator+ and operator= probably need some form of abuse.

On Sun, May 23, 2010 at 10:03 PM, Joshua D. Boyd &lt;jdboyd(a)jdboyd.net&gt; wrote: what he said. we can extend this to a lot of boost-covered stuff. a C implementation of boost::optional would be similarly opaque and clumsy, i think. i also can't begin to imagine how to implement scoped-lifetime objects in C. even without exceptions (which admittedly do cause some conceptual pain in C++), the ability to know that wherever you return from within a function, relevant local objects will be cleaned up has a significant simplifying effect on the design of a function. so yes, you can certainly get along without these ideas and write very sophisticated software. the issue is really about whether you want to. when i went to write a functor class a few months ago, i got about 90% of the way there in a few hours. then i went and read the boost headers and realized there was an entire universe of semantic details that i was overlooking and that to get all the way "there" would take me weeks, assuming i ever got there. so i could (a) do without functors or (b) use the boost implementation. i chose (a). --p

On Mon, May 24, 2010 at 3:03 AM, Joshua D. Boyd &lt;jdboyd(a)jdboyd.net&gt; wrote: That is a fair point. And it's not unreasonable to expect people to pick up idioms like that for concurrent programming -- it's not as if there is a broad language of equally effective alternative concepts in wide use. Chris

On Mon, May 24, 2010 at 5:12 AM, &lt;fons(a)kokkinizita.net&gt; wrote: it seems to me quite the opposite. most of these ideas are actually fairly old. they just never got implemented in or were never supported by a widely used language. i've seen very few "new" ideas show up in programming languages, but what i am happy to see is the relatively careful integration of some of the most useful and powerful idioms from other languages (lisp, python and so forth) into a language where i can actually control precisely what happens (C++). it turns out that there are two levels of care: first, those responsible for the std:: namespace (and even boost:: to some extent), and then myself as an individual programmer making choices about what to use. --p

On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote: I find this sort of thing absolutely beyond comprehension. It's impossible to understand without knowing the boost:: abstractions, templates and god knows what else. IMNSHO, the way any software works should be understandable by a) knowing the language, b) reading the code, at least up to the point that the reader can have an good idea of the big picture, of data structures and control flow, only excluding application domain specific details which require special expertise anyway. If libraries are used to somehow extend the language rather for encapsulating application domain specific algorithms, the net result is code that is utterly unreadable to anyone who happens not to use the same libraries. This is true for libs such as STL and to a larger degree, boost. Again IMNSHO, a programming language should be used 'as is', without trying to extend it or introduce concepts that are not part of it ('shared_ptr', 'promise' (whatever that means), 'spromise' (whatever that means), etc.). All the rest is just obfusciation, and useful only to some niche of 'believers'. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Sun, May 23, 2010 at 06:58:42PM -0400, Paul Davis wrote: I'm not using them, for various reasons: 1. Looked at the documentation and decided I didn't want this. Have you counted the number of caveats ? Just using an unnamed shared_ptr as function argument can be enough to invalidate the whole thing. 2. At least in the type of apps I write (DSP, RT), memory management should IMHO be explicit. Without that, you don't even have any idea if how much memory your code is using at any time, nor when some of it will be freed - it could very well happen at an unconvenient time. If you have to keep copies of a smart pointer just to make shure it won't call delete[] while in a RT context, then the whole point is lost. 3. I use C++, and all classes I write are designed to clean up after themselves, just as all threads are designed to terminate themselves explicitly and cleanly. Making sure that these things are correct takes some work, but the reward is a level of confidence I wouldn't have with any 'automated' way of doing this. It also forces you to _think_ about these things, which results in cleaner design. 4. In those cases where dynamically allocated objects move around between objects or threads and it's not clear who should take care of managing them, very often following some simple rules solves the problem. For example, the message objects used by clthreads are in their basic form not even reference-counted. The rules for using them are simple: when you receive one, or create one, you own it. After use, either delete it or send it to some other thread, and in boht cases assume it doesn't exist anymore. I *do* use setjmp/longjmp in one case, when interfacing with libpng which uses them for error recovery. I've never understood what's the point about the horrible thread local storage API. All threads I use are C++ objects, any non-static data members of such a class are local to the thread. That's all I need. You need to bootstrap thr_start() via a static C function once (using the void *arg as object pointer) and that's it. You could do the same in plain C as well, just putting all thread local data into a struct. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Tue, May 25, 2010 at 02:04:57AM +0200, Jens M Andreasen wrote: /me is still trying to figure out if thats funnier than a compile time raytracer :) http://ompf.org/forum/viewtopic.php?f=8&t=1556 -- torben Hohn

On Sun, May 23, 2010 at 11:12:22PM -0700, Niels Mayer wrote: paul argued about the usage of shared_ptr vs. plain C. shared_ptr is a form of garbage collection. its definitely part of c++0x stl. and yes. doing functional programming in c++ without shared_ptr would be pretty much impossible. for me the stl is an integral part of c++. and adding language features for things which can be implemented as part of the STL, escapes my understanding. c++ is a strongly typed language. it doesnt need language extensions, to model promises and futures. it needed a language extension for closures. it got that. clojure is dynamic. so you need some language extension to classify the dynamic types. i could reverse all this arguing, and argue that a dynamically typed language is not the right tool if your dynamic types need to end up being different types. because std::promise<boost::any> is different from boost::any likewise i predict, that people will be using promises in c++ too, once c++0x starts to be adopted. and people WILL pretty quickly jump onto the std::thread train. same thing with c++ promises... it was pretty much the same code as the clojure example. just in strongly typed language. the shared_ptr is the c++ way of opting in for garbage collection. and this is the only point that might be the c++ problem. it would probably smarter to opt-out of garbage collection. since one wants GC most of the time. but thats not how c++ evolved. right. bolting "types" onto a dynamically typed language ;) there has been an interesting demo of the dalvik vm on google io. http://www.youtube.com/googledevelopers#p/a/CF01A789E62F2454/0/IY3U2GXhz44 its demoed around 9:45 you see a game running in the new dalvik with a JIT and the old dalvik without. the game was modified to flash red when the framerate drops below 30fps. while the overall throughput of JIT vm is higher. it flashes a few times before the cpu load gets too high for the non JIT vm to go into deep red. when speaking strict RT performance the non-JIT vm performs better. the java JIT is probably better. but i doubt that anybody bothered to implement swapping in the new code in a lock free way. -- torben Hohn

On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote: well... basically c++0x is adding some of the cool features of python to c++ now. i recognise most stuff because its all the python neatness i always wanted to have in c++. std::map<std::string,int> m = { { "a", 1 }, { "b", 2 } }; -- torben Hohn

On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote: the [=] is the c++0x lambda/closure. [=] copies all referenced variables into the closure. i didnt really use it yet. and i am not sure how to indent it properly. but its basically an inplace function definition. [=] means COPY all referenced variables. [&] would mean reference. since the closure would be executed outside of the stack frame of osc_recv the spromise needs to be copied. yes. the other stuff is from boost::threads but will be in c++0x std:: namesapce. however gcc-4.5 doesnt have the threading in its std lib yet. although i looked and the future is already there. the availability of promisses is the major argument why people are pushing clojure. and writing equivalent code to using promises and futures without using them would be a bit pointless. they are in boost, and they will/are be in the std:: well... the lambdas are new to me too. never used them yet. note that this isnt stuff from the future. ok. it might change a bit. and probably gcc-4.5 shouldnt really be required until its 4.5.2 well... for me, saying c++, is saying boost. boost and modern c++ is what makes c++ better than java. java is a pretty great language nowadays (with generics and annotators and stuff). my big problem with java is that its stdlib is really a big mess. -- torben Hohn

On Mon, May 24, 2010 at 10:24:17AM +0100, Chris Cannam wrote: i dont know which features you mean. but not having typesafe containers like pre generics, puts the language on par with python for me. (except that in python i dont need to cast everything to the correct type after pulling it out of a container :S the language i am referring too is termed "modern c++" also i didnt port the jackdmp code. tschack is pretty different from jack2. i also only used boost because these parts of boost are going to show up in the STL. modern c++ heavily leverages templates and they were anticipating concepts to show up in c++0x which would have improved the error messages associated with template code. we wont have concepts. thats a bit sad. but this doesnt stop people from writing code in a concept oriented way. classic C++ and "modern c++" are two pairs of shoes. if your afraid of writing templates. modern c++ is not for you. for me templates are an integral part of c++. but i am also pretty annoyed if i read the compiler output asm and directly see somthing i could do better when i wrote the asm myself. i only do that for inner loops. but i also stop the heavy templating at some point and just write rather classic gui code then, or just wrap the whole bunch into a python extension. -- torben Hohn

On Mon, May 24, 2010 at 01:27:42PM +0100, Chris Cannam wrote: dunno. but wikipedia calls this particular style modern c++ http://en.wikipedia.org/wiki/Asio_C%2B%2B_library http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design seems to be based on the book: "Modern C++ Design" by Andrei Alexandrescu, the efficiency i am talking about is presenting the compilers optimizer with the whole algorithm. without hiding some parts behind a virtual method invocation. the difference is basically: class X { virtual void do_something(); } void well_do_something( X & x ) { x.do_something(); } vs. template <class T> void well_do_something( T & x ) { x.do_somthing(); } in the latter the compiler sees the complete algorithm. and can optimize properly. but this is the direction into which the whole STL is moving. yes. making a functor a real closure was pretty annoying. thats why boost::bind came to the rescue. but boost::bind is still pretty awkward compared to a c++0x lambda. -- torben Hohn

On Mon, May 24, 2010 at 02:28:03PM +0100, Chris Cannam wrote: i think you can. but i really dont think its so esoteric. the whole boost is using it. and boost is where most of the potential STL additions are maturing. -- torben Hohn

On Mon, May 24, 2010 at 08:28:14AM -0400, Paul Davis wrote: hmm... i dont really find GObject hard to work with. its simply the required boilerplate that puts me off. iE before just deriving from a gobject. you end up just instantiating the BaseClass and connecting signals to customise it. before you even consider deriving. just look to what kind of a monster this compiles to: http://www.jirka.org/gtk-button-count.gob. c-file: http://www.pastebin.org/274390 h-file: http://www.pastebin.org/274393 however once you need some kind of property or additional state on an object you really need to derive. (you can probably get away with g_object_get_data() but thats "teh ugliness" :D -- torben Hohn

On 05/20/2010 08:39 PM, Nathanael Anderson wrote: Well, this is a bit different, but I made an osc server with liblo in Jackbeat, and got no obscure issue IIRC. But I sense that you are a bit afraid about dealing with multiple threads. And in what you explain you'll still need an OSC thread in your daemon, which is waiting for OSC messages and dispatches them when they arrive. So you'll have to implement some kind of (IPC) communication channel between this thread and your RT thread. GUI or not, you have to deal with this ;-) Now, because you have an RT thread, there are some traditional IPC approaches that you can't use here. You can't do any blocking calls in the RT thread, so the usual mutex/lock-based IPC is not ok. What I do in this situation is sending messages from one thread to the other through a jack ringbuffer. This is 100% realtime-safe. -- Olivier

On Thu, May 20, 2010 at 5:30 PM, Olivier Guilyardi &lt;list(a)samalyse.com&gt; wrote: Being a long time Vim user is probably _why_ you found it to be so efficient ... ... now if you were an Emacs user, that'd be another matter ... Anyway, aside from Qt (which I also use and endorse) it might be worth looking at JUCE (http://www.rawmaterialsoftware.com/juce.php) and NUI (http://www.libnui.net/). I've never tried either myself but JUCE is quite widely used for audio applications, including by some Linux developers. Never really heard anything first-hand about NUI, but it has a natty website at least. Chris

On Fri, May 21, 2010 at 10:52 AM, Olivier Guilyardi &lt;list(a)samalyse.com&gt; wrote: Sorry, I was just being silly. I agree with you, Qt Creator is the first IDE a new Qt developer should look at. Chris