-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Wilms schrieb: Well you can design an fltk gui pretty well. GTKmm guis are always using your desktop theme which might be bad, too.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Davis schrieb: Thats interesting. Will have a look how this works. I think I'll go for gtkmm. I like the nice docu ;)

On Mon, 2009-08-10 at 12:10 -0400, David Robillard wrote: The default GTK+ Theme in the incarnation of Mandriva I have here is absolutely stunning and good looking ... But redraws at a crawl when the machine is close to full rt-dsp load. Hey, you can even watch how it paints the faders in gnome-volume-control from right to left when there is no load /at all./ Really, an Atari ST is more responsive. Another theme supplied with this dist (La-Ora Grey) looks almost as good and works just fine under heavy load. Now tell me again, what was the reason for choosing this theme rather than that theme?

On Mon, 2009-08-10 at 13:57 -0400, David Robillard wrote: Yes, but why is UNIX always by default configured in the least useful way?

On Tue, 2009-08-11 at 04:14 +1000, Patrick Shirkey wrote: As a comparison, the machine I have today is the equivalent of a Cray2 - the most outrageous 200KW 'supercomputer' of the time when (the quite responsive) Atari/Amiga were the bread and butter machines for audio/video hackers. Spending that much clockcycles on screen redraws of bland widgets just ain't sane anymore. Ohh, and I forgot: I even have a graphics card on top with computational power exceeding that of the Cray2 by a factor of four ... Still feels like my Linux desktop will be forever stuck on pear with that of a Spectrum-48 :-/ /j

Patrick Shirkey wrote: Software needed less resources in the 80ies, when we programmed in Assembler, but in the 80ies it was easy to keep track of things while programming for Z80, 6502, 6510 and 68000. I guess you Linux guys need to use C, because the CPUs and kernels have become much more complex. Ralf

On Mon, 2009-08-10 at 14:59 -0400, David Robillard wrote: This is such BS .. Let me Guess Intel? Opensource and broken GL!!!

On Mon, 2009-08-10 at 15:22 -0400, David Robillard wrote: Ah, your 2D driver works .. But that is not what I said.

On Mon, 2009-08-10 at 15:41 -0400, David Robillard wrote: OK, I have been around BIOS now, and changed the monitor connection as well (so I can see what I write ... ) I have no GL whatsoever now, but - lo and behold - Clearlooks is actually snappy? I wouldn't have believed that without trying it out. Going down again ... cu!

On Mon, 2009-08-10 at 22:04 +0200, Jens M Andreasen wrote: While I was at it, I updated my driver to the latest ... And you know what? (Yes, you probably gussed it :) Clearlooks is now snappy with Nvidia as well (driver 190.18, X:1.3.0 ) I wonder if this positive effect is also reflected in the behaviour of scrolling in Firefox at certain (most!) 'wordpress' sites, while simultaniously doing audio processing on the GPU ... So I suppose we can conclude that commercial vendors never fix bugs except for some of them and then only sometimes.

On Mon, 2009-08-10 at 17:14 -0400, David Robillard wrote: Hardware is the most humble later 8400GS (revision g98 [1.4 GHz × 8 madd]) Software is the free 'C for CUDA' compiler and SDK from Nvidia Mmmm, but !proprietary == !commercial (once the cat is out of the bag und so weiter und sofort ...)

On Mon, 2009-08-10 at 17:40 -0400, David Robillard wrote: What I do is - imagining that I am a Jack client with near zero processing time - what I do is that I 'receive previous/send next/launch kernel' in one go. Current process is in principle a 192 voice Minimoog style polysynth with 4 external audio inputs + a ton of midi in. Mixdown to 16 stereo (midi)channels, further mixdown to 8 out (1 stereo 'house' + 3 stereo 'fx send') Sorting the dynamically assigned voices to their respective channels is currently the main bottleneck - or so it seems. With buffersize 3 × 1.3 ms @96KHz I have clockcycles to spare and can at ease display a stream of video (320×200) simultaniosly for doing a soundtrack to some movie or something. And more ... With buffersize 3 × 0.7 ms .. I'll have to back off somewhat regarding number of voices. With buffersize 3 × 0.3 ms .... nope, can't do that, sorry! (but still works for code on the host) The Jack interface is not really here yet though. It must be understood that there can only be one transfer to the device for each run which must include all inputs, otherwise you'll get absolutely nothing done. That transfer can OTOH be pretty huge, way more than I personally have any use for at this point in time. 64in + 64 out @96KHz + lots of controllers, left in some place we all (as well as Jack) knows about would not be asking for too much from the hardware. That is not the problem. The general hostility against non-GPL software is tougher though, and unfortunately makes me feel like - by presenting these ideas - like I've just dressed up in pink rubber-suit with a sign on my back saying "puke on me" ... Oh well, you'll have to wipe off your own monitors when you are done :-D /j

On Mon, 2009-08-10 at 21:43 -0400, David Robillard wrote: Most certainly. The driver is very predictably processing each batch to completion, so if there are no X-events queued up, then you 'own' the GPU. Anything OpenGL and you're fried though - not even GLX gears in a small window, at least not with buffer sizes around 1ms. Increasing the buffers/jitter to around 5ms does away with that problem though, so that glxgears can run in 256×256 (along with the previous smallish video stream and Atari ST emulation [running a MIDI-sequencer]), oh and apparently also GLX in full screen. Increased buffers also does away with artifacts coming from certain Firefox redraws (where this site http://carlbildt.wordpress.com/ mysteriously is affected while this site http://arstechnica.com/ is not.) This is with the tiniest most out-fashioned device almost available which do not have newer features like overlapping processing/transfers for alternating streams. The motherboard chipset on say the ION-platform would have near twice the processing power, and you could then also do away with any transfers and just read from normal memory, leaving the Intel companion chip to do interrupt processing and nothing much else. If anybody would be interested in doing a concerted effort of optimizing PCIe transfers in jackd for cross platform CUDA audio processing, then - well - I am here, as well as over at the CUDA forums. I imagine that, as seen from say qjackctl, this should just look the same as any other hardware you may have - like a sound-card - with 32 or perhaps 64 channels in/out. What happens at the other side, what those channels connects to, would be up to the user/programmer. Running several kernels in succession, the one piped into the other has very little overhead, although it might be a better strategy to do different parts of the scene in parallel on neighboring processors. Very few people who does not work at TU-Berlin actually needs more than 640 channel strips ;) The reward would be having huge arrays of GHz processors for about one dollar a pop! Memory bandwidth in the triple digit range to go with that. Or like me, just enjoy the bliss of silent computing on something a little less ambitious. /j 8<-------------------------------------- update: The performance increase for GTK pixmaps I experienced earlier came because the X conf defaulted to 8bit after the Nvidia card was disabled ... darned! I'll have to redo that experiment with the Intel driver again some other day, and for now just remember that switching to 8bit might allow for more 'blinkenlights' while still processing near RT on the GPU.

On Tue, 2009-08-11 at 07:45 +0100, Steve Harris wrote: It is the scatter/gathering of data that is killing. I need to have one and only one transfer on the PCIe line for each period to be efficient, preferably in the 10 - 20KB range or more. The jack model of one channel, one buffer does not fit very well here. Potentially It should also be possible to stream from harddisk via DMA directly to the device without bothering the CPU at all. That OIOH hand would work for prerecorded material with say ardour, since you can look ahead as many bytes as you like. Doing live performances requres another approach though. Do you believe it would be very difficult to implement? I do unfortunately not have the required knowledege of jackd internals to judge wether or not.

Continuing this increasingly inaccurately christened thread .. On Tue, 2009-08-11 at 11:26 +0100, Steve Harris wrote: OK .. Adrian Knoth showed some interest and says he knows his way around in jackd as well as a colleague involved with CUDA. If the idea after evaluation does not appear to be worth the effort, then we'll just drop it by then. That would have to be a collection of generally useful plugins, at least 32 channels wide to be worth it. A mega plugin so to say. This ain't no lawn-mover you can turn around on a platter. Doing little things here and there /only/ would be very difficult in general. The thing to notice is that, although several kernels can be launched the one after the other, at any given time there is only one running which will have to be aware of which codepath to take depending on what processor it is running on. Or else you'll end up with 640 identical channel-strips rather than something like a synth-collection, 64 fully equipped channel-strips + a few reverb units as well as an autocomposer based on neural networks (Well OK, that last one might be a bit over the top... :) As long as you only have a single 8 core multiprocessor, the GPU can be utilized fully by a single somewhat demanding project. It is when there are dozens of cores to feed that the need for cooperation arises, and this is as far as I can see where things are heading, also over in Intel/Larrabee land. To some extent, yes. But provided that the host isn't spending much time on moving buffers around, you'll still have all of your (much more flexible) CPU left to use for additional processing. Having this much processing power available in a way also eliminates /the need/ for carefully selecting what channels should be processed by what plugin. Just do everything for all, possibly with all settings turned down to zero or bypassed on some, even most channels. Some effects will still be optional - like say time stretching, which might not be a natural choice for the basic bread-and-butter setup, no matter how much icing you put on it. Or maybe it is? Some people will most likely disagree with me here .. To put things in some economical perspective, I am talking about upgrading this tiny desktop-machine to having bandwidth and processing power twice that of a current top-of-the-line Intel Nehalem for less than $200, maybe around Christmas. Inexpensive (!Apple) laptops with GPU's like that are hitting the channel as we speak. /jma

On Tue, Aug 11, 2009 at 01:54:39PM +0200, Jens M Andreasen wrote: Speaking from the user's point of view, LV2 would be the way to go. It's just convenient to have all the settings saved in an ardour session, nice GUIs and so on. This could boil down to have a collecting thread somewhere and just small control plugins for getting the actual data. But I'm sure we'll find out. ;) I could imagine a generic all-in-wonder channel strip. (to the channel, it looks like a channel strip, but it's actually 32 or more channels in parallel). Which would mean: dynamics section (compressor, gate, gain), EQ, perhaps some fancy stuff like your rubberband or pitch correction in general, perhaps FFT analysis or at least FFT transformation, so subsequent plugins can operate in the frequency domain. Or whatever. ;) Doesn't sound too bad to me. ;) Though I could perfectly live with 128 identical channel strips plus your synth running, if switching kernels is feasible. Christmas? That's ambitious, but hey, I guess we could "borrow" lots of code from existing plugins and chain them together. Anyway, it's a cool project. -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver Gesundheit? - Was nützt einem Gesundheit, wenn man sonst ein Idiot ist? (Theodor W. Adorno)

On Wed, 2009-08-12 at 00:32 +1000, Loki Davison wrote: That's a very good question! One user vvolkov from Berkeley has posted some specially designed and optimized code for FFT sizes 256, 512, 1024, 2048, 4096 and 8192 here: http://forums.nvidia.com/index.php?showtopic=69801 He is claiming a throughput of no less than 160 Gflop on a GTX 280 (which is quite a high end card.) How much computational power is needed for jconv, just to get a rough estimate of whether this would be a good idea? Would it be correct to say that the expected number of flops for 8192 samples would be close to 8 × (8192/2) × log(8192) == approx 128000 flops, most of which can be executed as combined multiply-adds? Another user posted sometime ago windows binaries for a convolution reverb using the CUDA FFT library routines. It is a) unlike jconv using large same size segments b) perhaps not the most optimal solution for CUDA But as proof of concept, yes people have said that it works.

On Tue, Aug 11, 2009 at 06:50:50PM +0200, Jens M Andreasen wrote: Note that the algorithm implemented by libzita-convolver (used by jconv) when used in real-time mode relies on regular scheduling (i.e. being called from a Jack process callback) and carefully set thread priorities. How to structure a convolution engine to run on a graphics processor would very much depend on where you want the I/O. If it remains a Jack app then the easiest way would be to offload the work done for the larger partition size(s) to the graphics processor. Timing is absolutely not critical in that case, but if more than one partition size is moved in that way, or if you have more than one instance running you'd still need to respect relative priorities. Now jconv is a general purpose tool designed to efficiently handle any convolution matrix, including sparse ones. If you use it for reverb the matrix size is small (usually 1x2 or 2x2 for stereo). An application that runs e.g. 8 of those can be structured in a completely different way that could avoid the use of multiple priorities. Almost impossible to tell without trying. It also depends in a very complex way of the configuration - the ratios will not be the same on all machines. Jconv's predecessor, jace, worked by trying to distribute the work done on large FFTs and MACs as evenly as possible over callbacks with a shorter period. A condition for doing this is of course that you can estimate the work to be done in the first place. It was the impossibility of doing this for the more general use cases that jconv is supposed to handle that forced me to adopt the multi-threaded/multi- priority solution. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Tue, Aug 11, 2009 at 08:56:56PM +0200, Jens M Andreasen wrote: It's not that simple... An example: the santalucia reverb with period size = 256, mininum partition size = 256. There will be 3 partitions of 256 frames, 6 of 512, 6 of 2048 and 24 of 8192 frames. The first will be done in jack's callback and the others at lower priorities, resp. -1,-2,-3 relative to jack's thread (*). Each of these threads is triggered into action with a period equal to its partition size, and the work is expected to be ready at the next trigger. That means that the thread that does the size 512 ones must have priority over all the others. Except in some simple cases it's almost impossible to divide the work done by e.g. the slowest thread into equal parts. If that were possible we wouldn't need multiple threads at all - the evenly divided workload could be done in jack's callback without problem. As things are, pre-emption seems to be the only solution. No. The largest FFT used by jconv is 16k, it doesn't pay to increase that size. Depending on the configuration the FFTs could dominate the workload (many short 1-to-1 convolutions) or the MAC operartions would take most of the time (long IRs and/or a dense matrix). And then there's the cache size that will have all sorts of complicated effects. (*) From the next release that would be -1,-3,-5, i.e. one less for each doubling of the size. This allows multiple jconvs to be scheduled fairly even it they don't use the same set of sizes. Other apps doing similar things should use the same system if they are supposed to work together well. -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Wed, Aug 12, 2009 at 09:59:50AM +0200, Jens M Andreasen wrote: Actually 7,6,6,24. It would be 16K FFT, and there would be a lot more than just that. This is an outline of the process() function for one partition size: proces() { for (loop over inputs) { if (input not active) continue FFT } for (loop over outputs) { if (output not active) continue for (loop over inputs) { if ((input,output) not active) continue for (loop over partitions) { if (partition not empty) { MAC } } } IFFT } } The loops over inputs and outputs and the continue condition are actually inplemented by linked lists, but the code shown is equivalent. You could loop over the data structures, and make a list of of all steps (FFT, MAC, IFFT) and their parameters. Then if you know the relative cost of the three basic operations you try to divide this in 64 equal parts. There are some problems with this: - The relative cost of FFT and MAC is not know with any precision. - There may be less than 64 steps. - A single 16k FFT may already be too much, and most FFT libraries don't allow you to divide it into smaller pieces. Again, if you *can* do the division, there is no need to use multiple threads. you can just merge the lists of steps for all partition sizes and execute this as a static schedule using just function calls. This is how jace worked. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

Adrian I e-mailed you several times ... Am I blacklisted somehow? Anyways, the new fancy €70 card (Gigabyte GT220 OC) is in place here now. It is specced at approx 220 (bogo)flops. So far I have only been able to milk it for something like 50 Gflops using previous work naively scaled up to fill out the void. This at 3x16 samples @ 96kHz (no, not a typo), 128 channels in/out oldstyle slow PCIe 1.a, runlevel 2 and no monitor (this is important!). 256 channels works if you can do away with 3x64 (and the cost of the roundtrip to the GPU being 0.3ms rather than 0.16ms) /jma On Tue, 2009-08-11 at 14:43 +0200, Adrian Knoth wrote:

[renamed thread to reflect subject] On Sun, 2009-11-08 at 11:01 +0100, Adrian Knoth wrote: Independent kernels will on Fermi run at cluster-level. That is to say each kernel/application will - for the sake of efficiency - still have to fill four multi-processors, each running no less than six or eight warps of 32 element wide vectors. This is approximately the equivalence of current 9500GT or GT220 series. It is likely that in a production environment, audio will only be assigned one or two such clusters, one might be assigned for desktop video and the rest for 3D-rendering and psychedelica. So the audio challenge will not be much different from what you have today. Intgration with other applications using expertise from other fields than audio - like audio/video mix with pigs flying in the air - will be a lot more practical since a single PCIe slot can dedicatedly serve more than one purpose. This can in principle by using multiple boards be achieved already today also, but of course not as economically as it will be in the future. OTOH, everything will be better once that mythical tomorrow finally arrives .. You have ECC today? I haven't, but does that mean my Linux boxen is no good for computation? [No, of course not!] The C++ developments looks useful, but ... Python close to CPU programming? To me it looks like will you still have to write the GPU code in plain CUDA: http://documen.tician.de/pycuda/ /jma

On Tue, 2009-08-11 at 14:10 +0100, Steve Harris wrote: No, youd have to do your "stiching" .. .. at compile-time to get wildly diferent thing running simultaniosly on each processor. At least the code must be present and then you could do the final choice at kernel launch sending some parameter to the GPU to ponder on: switch(someArgument[blockID]) // we know where we are { case STRIP: ...; // do the channel strip thingie case MOOG: ...; // do classic synth case REVERB ... case FAIRLIGHT: ... case ... Well, almost that simple at least. There is still the 192 thread rule saying that you need at least 192 threads on each processor to fully hide pipeline latencies. Each "warp" - which is a group of 32 threads - can still take diferent codepaths though, as long as the programmer takes care that all paths will evt arrive at any synchronisation barrier issued by some other path. You'll get hung otherwise. Furthermore, all processor configurations will be the same. If one processor is configured for two blocks each having 128 threads, then that is how the world looks like for all codepaths on all processors. Still with me? In that case you are invited to do something wonderful for one (or more) multiprocessors, each having 256 threads divided between two blocks (128 threads per block) that will not use more than the available 16K registers defined by Compute Model 1.2 so that both blocks will run concurrently, hiding latencies as well as sync barriers. Figuring out where to read and write shared in/out in an organized way would in theory be the first minor obstacle, but nobody will notice before the individual parts of the project is eventually stiched together. Also, nobody knows yet what kind of processing will be available either or why anybody would like to read any other data, so .. Just to get going, say the kernel will be called every 128 samples at a samplerate suitable for the processor at hand. Assume something like a rate of 96K @1.2GHz Bah! /jma

On Mon, 2009-08-10 at 20:05 +0200, Jens M Andreasen wrote: My default theme, and that on most distributions, is stock ClearLooks, which is both attractive and relatively fast (and colour configurable) as far as I can tell. If your slowness is truly as bad as your description suggests, it sounds like you may have an X/driver/configuration problem. -dr

Jens M Andreasen wrote: For me TOS is still the best OS for MIDI usage with external MIDI equipment, but this isn't true, the Atari ST's response is very good when using a Blitter, but very bad when not using a Blitter. For Linux I noticed, that when running into trouble because of resources, ION2 is a very good WM, but sometimes ION2 has got troubles because of some windows behaviour. I can't remember the applicatuions, but if I would be a coder for Linux, I would take care about WMs that are frame based, without any DE. Ralf

Vincent Torri wrote: E17 looks well, but when I used it a long time ago on another machine it was disgusting experimental ;). I can't play the OGG? Are you sure that it isn't broken? Cheers, Ralf

Vincent Torri wrote: I'll try it again. I'm short of time now. It shouldn't be a problem because of the codes :S. Ralf

On Monday 10 August 2009 05:51:52 Thorsten Wilms wrote: There are other GUI toolkits that can look so much better. For instance, Qt and wxWidgets. Why are you settling for the two choices given? Raymond

On Monday 10 August 2009 06:11:08 Christian wrote: You can always recompile with less dependencies, and you do not have to use qmake to compile either. You can use CMake or something else. Seems like an odd reason to rule it out. Have you seen Audacity? Looks pretty good, IMO. Raymond

On Monday, August 10, 2009, Luis Garrido wrote: Agreed. Another excellent C++ multiplatform toolkit is Juce. It is worth to try it if you are writting audio/MIDI software. http://juce.sourceforge.net Regards, Pedro

On Mon, 2009-08-10 at 11:51 +0200, Thorsten Wilms wrote: Supercollider was some time ago. Current Version of FLTK has more than one engine, including one that clains to be a "Clearlooks" knock-off

Hello Ken! I can contribute little, but it may still push you in one direction. I've seen both some QT-code and understood it and I've seen some gtk+, which I had more problems understanding. So I think QT might be easier to implement. Also QT has a lot by itself, nice helpers. GTK now may be as easy to write, just me not understanding it, I'm not too bright at it though. But GTK is good to use for blind people, because of the Gnome people pushing some accessibiloity stuff. Also gtk and the glib have to offer many things, which might come in handy. One last remark and I drop off; GTK+ might not be that easy to read for me, because GTK is originally in C and gtk+ - as I understand - was kind of a complex wrapper for it. Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Thu, Aug 13, 2009 at 8:29 PM, David Robillard&lt;dave(a)drobilla.net&gt; wrote: As Pedro says, Qt just contains a code generator; you still end up with C++. I don't think the differences between Qt and libsigc++ signal/slot mechanisms are all that much to be worried about -- libsigc++ gets you "purer" C++ but Qt involves less typing, particularly of those pesky angle brackets. They both work. Good material for endless pub arguments, but not worth getting in a froth about when you're actually coding. (I generally use Qt, and I would say that Qt4 is a very fine library in general. Not much wrong with GTKmm either though.) Chris

If you are using GStreamer you might find GTK+ syntax very similar (I personally find everything GLib counterproductive and, generally, a sore to the eyes, but to each his own, a lot of very respectable software is based on it, so there must be something to it.) If you'd rather program in C++ then GTKmm is a wrapper around GTK. Bear in mind that Qt is C++ and signal/slot based, so you'll have the usual problem of integrating GStreamer callbacks using static methods and the user payload at the calls. If you are interested in an example I spent some time integrating GStreamer and Qt in this little project of mine (in the distant future I plan to drop GStreamer in favor of the infrastructure provided by Sonic Visualiser): http://sourceforge.net/projects/soundtoucher/ A lot more? Mmm, checkout complex GUI apps like Rosegarden, Muse, Qtractor, Musescore, Alsa Modular Synth, Sonic Visualiser... In the Music Application menu of my desktop the only non-Qt applications with a complex GUI are Ardour and Audacity. Qt has always been GPL for GPL projects, so it has been widely used by a lot of open source projects, no problems with the license whatsoever. If you have in mind a complex GUI and have little time to master a toolkit I'd go with Qt because of its straightforward syntax and thorough documentation. Otherwise, it is not really that important what toolkit you choose, so I'd favour GTK because of its easy integration with GStreamer and to keep the whole application under the callback paradigm. HTH, Luis

On Friday, August 14, 2009, Paul Davis wrote: Of course you need a pre-processor to use libsigc++. The pre-processor is a standard part of the C++ (or plain C) compilation chain, for instance the "cpp" program for the GCC compiler. It takes care of expanding macros, compile directives and conditional compilation. Maybe you are thinking about the Qt's "moc" code generator tool. It reads a C++ header file, and if it finds one or more class declarations that contain the Q_OBJECT macro, it produces a C++ source file containing the meta-object code for those classes. This code implements the calls and callbacks for Qt's native signals and slots, among other things. MOC is not a pre-processor because it doesn't replace any text in the original header file before the next compilation step. It is only a code generator. The original header is a standard C++ header that can be used as-is by a C++ compiler. The main (functional) difference between the two systems is that Qt's signals and slots can be manipulated at runtime, while you can't do the same with libsigc++, that freezes the connections at compile time. Manipulate means that you can connect and disconnect signals and slots at runtime, store and retrieve those connections from a text or XML file, and so on. This also makes Qt's signal/slots a little more expensive in processing time over libsigc++. Here is a comparision between them: http://libsigc.sourceforge.net/benchmark.shtml Why Doesn't Qt Use Templates for Signals and Slots? http://doc.trolltech.com/templates.html Qt's native signal/slot mechanism isn't mandatory to developt Qt-based applications. It is possible to use Boost, libsigc++ or something else. See: http://doc.trolltech.com/signalsandslots.html#using-qt-with-3rd-party-signa… Regards, Pedro

On Fri, Aug 14, 2009 at 2:36 PM, Ray Rashif&lt;schivmeister(a)gmail.com&gt; wrote: Or NUI: http://www.libnui.net/ ... I've never tried this, would be interested in impressions from anyone who has. Chris

Hey all, I've just downloaded and built NUI, it seems ok, a little "plastic"-"shiny" looking, and the sliders run kinda slowly on this laptop. (Havent tried anywhere else.) GTK(mm) sliders work no prob here on the other hand but I develop with GTK, so my view is biased ;-) Their screenshots look nice though.. and there's pretty nifty docu with it by the looks! -Harry