Re: [LAD] Looking for an introduction to rt programming with a gui
On Thu, May 20, 2010 at 06:46:16PM -0400, Paul Davis wrote: > 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.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 > >> 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 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 > python. this was done using automated tools followed by some hand-tweaking > (it involved parsing all the C++ and generating XML descriptions of every > data structure/object, and then feeding that into a python external > generator). > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev -- torben Hohn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] interesting TSC coverage on lwn.net
On Thu, May 20, 2010 at 11:04:29PM +0200, lieven moors wrote: > On 05/20/2010 09:08 AM, Jörn Nettingsmeier-6 wrote: > > hi *! > > > > in the light of recent timer discussions (was it here or on > > jack-devel?), lwn.net has interesting coverage about the time stamp > > counter and its oddities in the recent weekly edition: > > http://lwn.net/SubscriberLink/388188/62e8027425e224f6/ > > (free link, the rest of the issue will become available to > > non-subscribers in 14 days or so.) > > > > best, > > > > jörn > > > > ___ > > Linux-audio-dev mailing list > > linux-audio-...@... > > http://lists.linuxaudio.org/listinfo/linux-audio-dev > > Thanks for the link! > Interesting read. > So this is the monster that's being used when you start jack with -c > cycle... yeah. dont do it. -- torben Hohn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
Niels was all like: > Any dev's here implement a loosely decoupled frontend/backed like this > before and run into issues i with it? > Implemented a GUI / Engine style program with OSC inbetween: Yup. C++ & LibLO & GTKmm Run into issues with it: Nope. There have been some minor OSC issues, but I'm confident that they're my misuse of the libLO.. :-) If your intrested the sources of the implementation are available here: http://github.com/harryhaaren/Luppp Cheerio, -H PS: Although the project is in some working state, its really is a WIP. The OSC code is pretty OK i think, but there are some bad decisions made with regard to classes and "static" data attributes. Keep that in mind.. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
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.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 >> 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 python. this was done using automated tools followed by some hand-tweaking (it involved parsing all the C++ and generating XML descriptions of every data structure/object, and then feeding that into a python external generator). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
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 > 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): (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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] interesting TSC coverage on lwn.net
On 05/20/2010 09:08 AM, Jörn Nettingsmeier-6 wrote: > hi *! > > in the light of recent timer discussions (was it here or on > jack-devel?), lwn.net has interesting coverage about the time stamp > counter and its oddities in the recent weekly edition: > http://lwn.net/SubscriberLink/388188/62e8027425e224f6/ > (free link, the rest of the issue will become available to > non-subscribers in 14 days or so.) > > best, > > jörn > > ___ > Linux-audio-dev mailing list > linux-audio-...@... > http://lists.linuxaudio.org/listinfo/linux-audio-dev Thanks for the link! Interesting read. So this is the monster that's being used when you start jack with -c cycle... Greetings, lieven ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Thu, May 20, 2010 at 5:30 PM, Olivier Guilyardi wrote: > Qt is really great. I also highly recommend that you look at Qt Creator which > is > included in the SDK. Although I'm a long time Vim user, I really found this > IDE > to be extremely simple and efficient. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Thu, 20 May 2010, Chris Cannam wrote: When I released the Composite Sampler, I had to solve two tricky bugs: Hang on -- I've never actually looked at Composite (sorry!) but does this mean that it has a Qt GUI that loads in-process in GTK-based LV2 hosts? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Thu, May 20, 2010 at 6:26 PM, Gabriel M. Beddingfield wrote: > On Thu, 20 May 2010, Charles Fleche wrote: > >>> well (e.g. if you write LV2 plugins based on Qt, as I have, you may >>> uncover some strange bugs). >> >> Really ? What happened ? > > When I released the Composite Sampler, I had to solve two tricky bugs: Hang on -- I've never actually looked at Composite (sorry!) but does this mean that it has a Qt GUI that loads in-process in GTK-based LV2 hosts? And besides the odd hiccup, that works OK? Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On 05/20/2010 08:39 PM, Nathanael Anderson wrote: >Cons: Uses a pre-compiler for generating "signal/slot" connections, > Several of the core classes (like QString) will spread virally through > your code. Because it's a full framework, it sometimes doesn't mix > well (e.g. if you write LV2 plugins based on Qt, as I have, you may > uncover some strange bugs). > > > As the gui is only used for configuring options, and not interaction > while the program is running (a restart is fine in this use case) I'm > leaning to a basic c/c++ daemon with osc i/o (udp, non blocking, brain > dead easy to use :) ) to communicate with a front end . . . which also > lets me focus more on fast tracking features into the backend, and at > lease initially just putting a hacky gui together, with very loose > coupling between the 2. I know sooperlooper and linuxsampler both > support modes of operation like this. Any dev's here implement a loosely > decoupled frontend/backed like this before and run into issues i with it? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
> > Cons: Uses a pre-compiler for generating "signal/slot" connections, > Several of the core classes (like QString) will spread virally through > your code. Because it's a full framework, it sometimes doesn't mix > well (e.g. if you write LV2 plugins based on Qt, as I have, you may > uncover some strange bugs). > As the gui is only used for configuring options, and not interaction while the program is running (a restart is fine in this use case) I'm leaning to a basic c/c++ daemon with osc i/o (udp, non blocking, brain dead easy to use :) ) to communicate with a front end . . . which also lets me focus more on fast tracking features into the backend, and at lease initially just putting a hacky gui together, with very loose coupling between the 2. I know sooperlooper and linuxsampler both support modes of operation like this. Any dev's here implement a loosely decoupled frontend/backed like this before and run into issues i with it? Nathanael ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
I agree with the Qt option, as it clearly produces some nice & performant music applications. But you're still programming in C++ which is tedious because of memory management; also "hard realtime" often precludes the use of Garbage collectors. Of course Java has RT garbage collectors available: http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/ although some may find "soft realtime" garbage collection as provided by the new G1 garbage collector sufficient: http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf ... see also: http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html Lots of interesting Java-based music apps exist, with GUIs: http://jmusic.ci.qut.edu.au/applications.html http://www.softsynth.com/links/java_music.html GUI application programming might be a little more forgiving in Java, although Java is a pain-in-the ass language, where you spend more time building and understanding scaffolding than you actually do programming... part of the scaffolding are the "design patterns" needed to work-around fundamental issues with primitive strongly typed languages like Java and C++ ( http://www.tiagoluchini.eu/2007/07/28/strategy-pattern-comparing-java-x-lisp/ ). The good thing is you don't need to use Java anymore, but can take advantage of its portability, security, advanced garbage-collection options, and just-in-time compiler advances that may give it a performance advantage, these days But you don't have to program in Java, you write in http://groovy.codehaus.org/ or http://clojure.org which means you can do really high-level things with just a few lines of groovy code ( http://lists.xwiki.org/pipermail/users/2009-August/016937.html ). Fortunately, several million unfortunate souls have slogged through all the hard work and made a huge library of functionality for people to use, much of it open source. http://curious-attempt-bunny.blogspot.com/2009/01/simple-clojure-graphics-api.html is a good example of the concision made possible by clojure... Clojure may be of particular interest in realtime multiprocessor/multithreaded apps because of its high level., language-level support for concurrency and multithreaded programming ( http://clojure.org/concurrent_programming ) as well as potential support for Software Transactional Memory, which is analogous to garbage colleciton for threads ( http://www.stanford.edu/class/cs242/readings/TMvsGC.pdf http://java.ociweb.com/mark/stm/article.html ). Niels http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Thu, 20 May 2010, Charles Fleche wrote: well (e.g. if you write LV2 plugins based on Qt, as I have, you may uncover some strange bugs). Really ? What happened ? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
Hi Nathanael, On 05/20/2010 01:35 PM, Nathanael Anderson wrote: > I've written some small c/c++ programs for my own use that were alsa > midi based. I found a very low entry barrier to getting started writing > console apps with alsa midi. I'd like to work on something a little > larger scale, and include jack midi with a gui to configure options, but > have no idea where to start. > > I'd ideally like to use a loolkit that provides skinable interfaces, and > I'm familiar with html/css layout, so something where I can build the > gui from a layout file would be nice. If it can handle threading issues > for me (rt worker and non rt gui) even better. Qt is really great. I also highly recommend that you look at Qt Creator which is included in the SDK. Although I'm a long time Vim user, I really found this IDE to be extremely simple and efficient. The GUI interface designer is also directly integrated into Qt Creator. Threading is really intuitive in Qt to me. Just extend QThread and implement run(), done (well, almost ;). About "skinning": http://doc.trolltech.com/4.3/stylesheet.html "The concepts, terminology, and syntax of Qt Style Sheets are heavily inspired by HTML Cascading Style Sheets (CSS) but adapted to the world of widgets" > What choices do I have for tools to use, and what pro's/con's are > attached to them. From what i've read so far qt seems like it might be a > good choice, aside from the high entry barrier of learning how to do > everything the qt way. Gabriel already mentioned some pros and cons, but if that matters to you, Qt provides quite amazing portability to other operating systems. I used it to develop a win32 app for one my of customer, almost only working on Linux. I really don't think there's such a high entry to the learning curve. It's all plain C++, and the specific signal/slot syntax is intuitive. Qt is not such a world apart IMO. I've used Gtk a lot, and I really like it too, but I was amazed about how productive I got as soon as I started using Qt. Hope that helps, -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
> What choices do I have for tools to use, and what pro's/con's are attached > to them. From what i've read so far qt seems like it might be a good choice, > aside from the high entry barrier of learning how to do everything the qt > way. > > I'm looking for information on any of the above. > > Hey, I've put some of my sample programs / tiny little programs up on the net: http://harryhaaren.blogspot.com/ There's nothing too complicated, as im still learning threading and advanced GUI / Worker stuff myself. If your using JACK then it takes care of some of the RT stuff for you... :-) -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
well (e.g. if you write LV2 plugins based on Qt, as I have, you may uncover some strange bugs). Really ? What happened ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] interesting TSC coverage on lwn.net
On Thu, 2010-05-20 at 16:08 +0200, Jörn Nettingsmeier wrote: > http://lwn.net/SubscriberLink/388188/62e8027425e224f6/ There is a link in the article to something Thomas Gleixner said: "Dream on while working with the 2 machines at your desk which" "represent about 90% of the sane subset in the x86 universe!" Any idea which 2 'sane' machines these would be? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
Excerpts from Arnout Engelen's message of 2010-05-20 16:19:01 +0200: > On Thu, May 20, 2010 at 08:37:07AM -0500, Gabriel Beddingfield wrote: > > Another option is to use a scripting language (like Tcl/Tk, PyGtk, or > > PyQt) for the GUI parts. However, when you're mixing it with your > > core C/C++ parts, I find it really hard to debug these programs. > > While working on jack_mixer[1], I was pleasantly surprised by being able > to use gdb to get backtraces from the C code even when it was called from > the Python frontend. > > The interfacing between Python and C could be easier though. > > > Regards, > > Arnout > > [1] http://home.gna.org/jackmixer/ 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] interesting TSC coverage on lwn.net
2010/5/20 Jörn Nettingsmeier > hi *! > > in the light of recent timer discussions (was it here or on jack-devel?), > lwn.net has interesting coverage about the time stamp counter and its > oddities in the recent weekly edition: > http://lwn.net/SubscriberLink/388188/62e8027425e224f6/ > thanks so much for that! fantastic reading. well, ok, not up for a nobel but you know what i mean :) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Thu, May 20, 2010 at 08:37:07AM -0500, Gabriel Beddingfield wrote: > Another option is to use a scripting language (like Tcl/Tk, PyGtk, or > PyQt) for the GUI parts. However, when you're mixing it with your > core C/C++ parts, I find it really hard to debug these programs. While working on jack_mixer[1], I was pleasantly surprised by being able to use gdb to get backtraces from the C code even when it was called from the Python frontend. The interfacing between Python and C could be easier though. Regards, Arnout [1] http://home.gna.org/jackmixer/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] interesting TSC coverage on lwn.net
hi *! in the light of recent timer discussions (was it here or on jack-devel?), lwn.net has interesting coverage about the time stamp counter and its oddities in the recent weekly edition: http://lwn.net/SubscriberLink/388188/62e8027425e224f6/ (free link, the rest of the issue will become available to non-subscribers in 14 days or so.) best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Thu, May 20, 2010 at 6:35 AM, Nathanael Anderson wrote: > What choices do I have for tools to use, and what pro's/con's are attached > to them. From what i've read so far qt seems like it might be a good choice, > aside from the high entry barrier of learning how to do everything the qt > way. Qt is not a bad choice. If you've not done any GUI programming before, then I recommend the book "C++ GUI Programming with Qt 4" by Blanchette and Summerfield.[1] Pros: Excellent documentation, good library support, is a full framework, themeable, etc. Cons: Uses a pre-compiler for generating "signal/slot" connections, Several of the core classes (like QString) will spread virally through your code. Because it's a full framework, it sometimes doesn't mix well (e.g. if you write LV2 plugins based on Qt, as I have, you may uncover some strange bugs). Other options include GTK+ (gtkmm), WxWidgets, and FLTK... but since I haven't dealt much with them I won't comment. Another option is to use a scripting language (like Tcl/Tk, PyGtk, or PyQt) for the GUI parts. However, when you're mixing it with your core C/C++ parts, I find it really hard to debug these programs. HTH, Gabriel [1] http://qt.nokia.com/developer/books/cpp-gui-programming-with-qt-4-2nd-edition ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Looking for an introduction to rt programming with a gui
I've written some small c/c++ programs for my own use that were alsa midi based. I found a very low entry barrier to getting started writing console apps with alsa midi. I'd like to work on something a little larger scale, and include jack midi with a gui to configure options, but have no idea where to start. I'd ideally like to use a loolkit that provides skinable interfaces, and I'm familiar with html/css layout, so something where I can build the gui from a layout file would be nice. If it can handle threading issues for me (rt worker and non rt gui) even better. What choices do I have for tools to use, and what pro's/con's are attached to them. From what i've read so far qt seems like it might be a good choice, aside from the high entry barrier of learning how to do everything the qt way. I'm looking for information on any of the above. Thanks Nathanael ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
