Re: [LAD] Looking for an introduction to rt programming with a gui
On 05/20/2010 10:12 PM, Chris Cannam wrote: > 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 ... Well, intellisense in QtCreator is really nice, especially when you learn Qt. And it's not as noisy as Eclipse which checks and underlines everything in red whenever you start typing something... I'm not sure whether Emacs can do intellisense, but anyway QtCreator is very good for learning IMO, and that's what Nathanael may need. Intellisense/completion, integrated documentation, etc.. Just download the SDK and start coding, everything's in it. Emacs wouldn't help in regard to the learning curve here... Personally, all these coding aids start to break my concentration after a while, I prefer the Vim blank page ;), but that's another topic.. > 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. True, JUCE is really nice, I've used it quite a lot. For instance, it's certainly better suited for plugins than Qt, as that came out on this thread. But it's far from being as mature and documented as Qt. JUCE may be funnier though.. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] update: OT-ish: realtime 2d placement algorithms :-/
Just a quick update. I eventually settled on a 64bit 2D array, with each 64bit element in the array representing 64 spaces in the grid merely for tracking the state of space being used or unused. Turns out much faster this way. There will still be a list of blocks (or windows if it was a window manager) placed but this is an entirely separate issue. For example in the test code I keep track of the coordinates (returned by the algorithm) and dimensions of placed blocks in an array. code/demo here: http://jwm-art.net/boxyseq/freespace_grid.tar.bz2 video/demo here: http://jwm-art.net/art/freespace_grid.ogv running 'make' in the src, builds a demo/test program which produces similar output to the video - this is where the good old xterm wins - set font to 'tiny' and maximize vertically and widen it to atleast 128 chars and xterm displays fast enough it looks like an animation. I'm hoping this will work well enough for real-time placement, though the worst case scenario has changed from just being 255 windows placed, to something like placing a 1x1 block in a non-empty grid full of (any dimensioned window... it's difficult to work out the worst case here. james. On Fri, April 30, 2010 23:10, James Morris wrote: > Hello, > > I'm still trying to develop my boxy-sequencer idea. Basically, I've tried > out a couple of algorithms for window-manager-like box placement within a > grid and run into big problems. > > Because I need help/advice/ideas, I'm posting here as it has some > relevance, and I've also posted to > > http://stackoverflow.com/questions/2746590/fast-block-placement-algorithm-advice-needed > > A quick run down of what's happened so far, the two algorithms: > > The first I directly based on Fluxbox's Row Smart placement algorithm. > Testing only the data structures, (and with gcc -O0) jack kicked out my > client after around 200 boxes were placed in a 128x128 grid. I then > counted how many times the algorithm looped through the entire list of > boxes and discovered (not in RT for this) that the 256th box placement > required around 14000 scans through the list of 255 previously placed > boxes (i've decided 256 boxes will be the worst-case-scenario). > > The second algorithm consists of a freebox data structure which represents > a rectangular area of free unused space. It also forms a node in a doubly > linked list, as well as four directional links to other freeboxes touching > it (with a maximum of one freebox touching each side of a freebox)... > turns out rather complex to implement fully: 700+ loc for a partial > implementation of row-smart left-to-right top-to-bottom placement - theres > also col-smart, r-to-l, b-to-t and all combinations. > > Through stackoverflow, I've come across spatial hashing. > > I wondered if anyone here uses this technique for the display of data > (would scrollable window views use such a thing?). worth it for a 128x128 > grid etc? > > I'm just after any general thoughts/insights you might have as to what > might or might not work. Anything worth pursuing. > > I'm afraid there's all sorts of little things to be considered so if you > do have something to suggest, please read the stackoverflow post first. > > Cheers for any help, if possible, > James. > > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] update: OT-ish: realtime 2d placement algorithms :-/
On Fri, May 21, 2010 11:30, James Morris wrote: > Just a quick update. I eventually settled on a 64bit 2D array, with each > 64bit element in the array representing 64 spaces in the grid merely for > tracking the state of space being used or unused. Turns out much faster > this way. There will still be a list of blocks (or windows if it was a > window manager) placed but this is an entirely separate issue. For example > in the test code I keep track of the coordinates (returned by the > algorithm) and dimensions of placed blocks in an array. > > code/demo here: http://jwm-art.net/boxyseq/freespace_grid.tar.bz2 not very portable: uses GCC builtins ctzl, and clzl, and probably other stuff not so portable. > > video/demo here: http://jwm-art.net/art/freespace_grid.ogv > > > > running 'make' in the src, builds a demo/test program which produces > similar output to the video - this is where the good old xterm wins - set > font to 'tiny' and maximize vertically and widen it to atleast 128 chars > and xterm displays fast enough it looks like an animation. > > > I'm hoping this will work well enough for real-time placement, though the > worst case scenario has changed from just being 255 windows placed, to > something like placing a 1x1 block in a non-empty grid full of (any > dimensioned window... it's difficult to work out the worst case here. > > james. > > > On Fri, April 30, 2010 23:10, James Morris wrote: >> Hello, >> >> I'm still trying to develop my boxy-sequencer idea. Basically, I've >> tried >> out a couple of algorithms for window-manager-like box placement within >> a >> grid and run into big problems. >> >> Because I need help/advice/ideas, I'm posting here as it has some >> relevance, and I've also posted to >> >> http://stackoverflow.com/questions/2746590/fast-block-placement-algorithm-advice-needed >> >> A quick run down of what's happened so far, the two algorithms: >> >> The first I directly based on Fluxbox's Row Smart placement algorithm. >> Testing only the data structures, (and with gcc -O0) jack kicked out my >> client after around 200 boxes were placed in a 128x128 grid. I then >> counted how many times the algorithm looped through the entire list of >> boxes and discovered (not in RT for this) that the 256th box placement >> required around 14000 scans through the list of 255 previously placed >> boxes (i've decided 256 boxes will be the worst-case-scenario). >> >> The second algorithm consists of a freebox data structure which >> represents >> a rectangular area of free unused space. It also forms a node in a >> doubly >> linked list, as well as four directional links to other freeboxes >> touching >> it (with a maximum of one freebox touching each side of a freebox)... >> turns out rather complex to implement fully: 700+ loc for a partial >> implementation of row-smart left-to-right top-to-bottom placement - >> theres >> also col-smart, r-to-l, b-to-t and all combinations. >> >> Through stackoverflow, I've come across spatial hashing. >> >> I wondered if anyone here uses this technique for the display of data >> (would scrollable window views use such a thing?). worth it for a >> 128x128 >> grid etc? >> >> I'm just after any general thoughts/insights you might have as to what >> might or might not work. Anything worth pursuing. >> >> I'm afraid there's all sorts of little things to be considered so if you >> do have something to suggest, please read the stackoverflow post first. >> >> Cheers for any help, if possible, >> James. >> >> >> > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > ___ 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 10:37:30AM -0700, Niels Mayer wrote: > 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 yeah... Java RTS has an innovative pricing model that starts at $6500 per socket/CPU for development or internal deployment. well... thanks :S > 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 hmm... maybe this actually works. still relies on some particular jvm. effectivily throwing away the whole portability mumbojumbo. > > 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/ > ). i dont understand... are you seriously arguing that dynamic languages are always better ? this certeinly isnt the case for number crunching. and i really find bigger programs pretty confusing in dynamic languages where variables arent annotated with types. > > 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... i think that code is pretty hard to read. and concision isnt always good. there is a reason why people call perl a "write-only" language. > > 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 ). i really dont see any advantage over faust here. au contraire. a quick glance on the clojure stuff tell me that you still need to manage concurrency in some way. while faust is able to parallelize any valid faust code. overall when it comes to RT stuff either you use a language which gives you control over heap allocation. or the language must be specifically designed for RT operation. so we end up with c/c++ again. or faust. and angelscript would be a valid interpreted language. because it gives the hosting app complete control over all allocations going on. all this stuff you posted is nice... but i dont really have any hopes, that this stuff would become useable in the next 2 years. stop dreaming :) -- 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
On Fri, May 21, 2010 at 8:33 AM, torbenh wrote: > On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote: > > 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 > > yeah... > Java RTS has an innovative pricing model that starts at $6500 per > socket/CPU for development or internal deployment. > > well... thanks :S 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_641: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. > i dont understand... are you seriously arguing that dynamic languages > are always better ? 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. > this certeinly isnt the case for number crunching. > 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 > where variables arent annotated with types. > 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. > i think that code is pretty hard to read. > and concision isnt always good. To each his own... > there is a reason why people call perl a "write-only" language. > 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. > au contraire. a quick glance on the clojure stuff tell me that > you still need to manage concurrency in some way. > > while faust is able to parallelize any valid faust code. > 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 > diagram algebra and lambda calculus and y-combinators?? (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 --> > http://en.wikipedia.org/wiki/Rewriting#The_Church-Rosser_property_and_confluence (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 > overall when it comes to RT stuff either you use a language which > gives you control over heap allocation. or
Re: [LAD] Looking for an introduction to rt programming with a gui
On Fri, May 21, 2010 at 7:42 PM, Niels Mayer wrote: > 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 >> diagram algebra and lambda calculus and y-combinators?? >> >> (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 I don't understand. What answers the question? Actually I'm not sure I understand the question either -- do you mean to ask why the block diagram algebra (which I guess was something from the presentation?) is being talked about when the lambda calculus already existed? 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 Fri, May 21, 2010 at 10:52 AM, Olivier Guilyardi wrote: > On 05/20/2010 10:12 PM, Chris Cannam 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 ... > > Well, intellisense in QtCreator is really nice, especially when you learn Qt. Sorry, I was just being silly. I agree with you, Qt Creator is the first IDE a new Qt developer should look at. 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 Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote: > On Fri, May 21, 2010 at 8:33 AM, torbenh wrote: > > On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote: > > > "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/ > > > > Java RTS has an innovative pricing model that starts at $6500 per > > socket/CPU for development or internal deployment. > > > > well... thanks :S > > Java is open source. 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. > 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). 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 dont understand... are you seriously arguing that dynamic languages > > are always better ? > > No! (...) 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. 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 ;). > > faust is able to parallelize any valid faust code. > > 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 > > diagram algebra and lambda calculus and y-combinators?? 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/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is there any hope for ReZound?
On Tue, 18 May 2010 19:25:40 +0400 alex stone wrote: > On Tue, May 18, 2010 at 12:49 PM, Louigi Verona > wrote: > > Hey guys! > > > > ReZound to me seems like one of the best sound editors on Linux. > > Yet, it appears to have been forgotten. Any hope its development > > and maintenance will be resumed? > > > > Louigi. > > > > ___ > > Linux-audio-dev mailing list > > Linux-audio-dev@lists.linuxaudio.org > > http://lists.linuxaudio.org/listinfo/linux-audio-dev > > > > > > You're right to be concerned, Louigi. It'll be a sad day when Rezound > finally rolls over and dies, because it's too old to run. Great app > that just works. > > Alex. > Yes, rezound is very good and from what I can see this is widely agreed upon. Something like it is really missing on linux... renato ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is there any hope for ReZound?
On Fri, May 21, 2010 at 11:32:53PM +0200, Renato wrote: > rezound is very good and from what I can see this is widely agreed > upon. Something like it is really missing on linux... Uh, except rezound is actually available on linux? Arnout ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is there any hope for ReZound?
On Fri, 21 May 2010 23:46:35 +0200 Arnout Engelen wrote: > On Fri, May 21, 2010 at 11:32:53PM +0200, Renato wrote: > > rezound is very good and from what I can see this is widely agreed > > upon. Something like it is really missing on linux... > > Uh, except rezound is actually available on linux? > > > Arnout of course :) I mean that leaving rezound to a soft death leaves a gap: there's no other linux app quite like it renato ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ANN] Qtractor 0.4.6 - The Funky Deviless is here!
So much to tell, even more to do... then one could hardly shake, this long overdue. Lousy rhymes and no miserly times. And there it is: a bug-fix release, I'll mean to ease. Oh crap! Let's get it through once and for all. With huge compliments to all who got the nerve and report as many too much idiosyncrasies (nee bugs). Don't, never look back. There's plenty more ahead, no matter where you look, or hear, whether is up or down hill :) Qtractor 0.4.6 (funky deviless) is here! Release highlights: - MIDI Editor draw mode (aka paint mode) (NEW) - MIDI Swing-quantize (NEW) - LV2 UI Instance & Data-access extension support (NEW) - JACK Session support (EXPERIMENTAL) (NEW) - LV2 Save/Restore extension support (NEW) - MIDI Editor event list in-line editing (NEW) - MIDI Clip time-stretching (FIX) - MIDI Clip editor file salvage quietness (NEW) - MIDI Control bus switching crash (FIX) - MIDI Bank-selection backout (FIX) - Initial widget geometry extents (FIX) - Input-only bus playback crash (FIX) - Bus connection persistence crash (FIX) - Drag-and-drop cloning plugins (FIX) - MIDI Editor floating-selection persistence (NEW) - Audio inserts garbage signal (FIX) A bit more or not so detailed change-log is found below. Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.4.6.tar.gz - source package (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.src.rpm - binary packages (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.i586.rpm http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.x86_64.rpm - binary packages (Ubuntu 10.04): http://downloads.sourceforge.net/qtractor/qtractor_0.4.6-4.rncbc.ubuntu1004_i386.deb http://downloads.sourceforge.net/qtractor/qtractor_0.4.6-4.rncbc.ubuntu1004_amd64.deb - user manual (outrageously outdated): http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License (no kiddin'): Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - Introducing a non-painting edit sub-mode on the MIDI clip editor's piano-roll (see Edit/Select Mode/Edit Draw menu). - The MIDI clip editor (aka piano-roll) is now a lot more quiet about saving its own dirty content, delegating all salvage questions to main session control. - Don't show session restart message box when changing JACK transport mode option anymore. - Dedicated MIDI control bus switching fixed. Was closing the wrong bus eventually and crashing the whole show with it (fixes bug #2989590). - MIDI bank/program backout has been corrected on MIDI track properties dialog rejection (ie. user cancellation). - MIDI bank select method has been corrected for tracks with no instrument defined (probably fixing bug #2987071). - LV2 UI Instance and Data Access extension support added; reduce LV2 external UI parameter value update flickering. - JACK session infrastructure support. (EXPERIMENTAL) - Initial widget geometry and visibility persistence logic has been slightly revised as much to avoid crash failures due to wrong main widget hidden state. - Initial mixer widget extents are now set reasonably larger. - General source tree layout and build configuration change. - Ever since smooth-ramping introduction that having at least one input-only buses were causing immediate playback crashes, now hopefully fixed. - Refactored for common engine client nomenclature, primarily provided by JACK, then secondarily passed to ALSA Sequencer, getting rid of the JackUseExactName requirement and lifting the unique/single instance restriction in the process. - Current JACK Transport, MMC Device, and MIDI Song Position pointer (SPP) control modes are now saved/loaded as part of session option properties. - MIDI clip editor's context menu crash on Qt >= 4.6 has been fixed (resolving bug #2972603). - An ancient double-free corruption has been finally fixed at the audio/MIDI bus connection persistence logic. - Improved visibility of track state buttons text (R, M, S) when turned on dark colored themes. - LV2 Save/Restore extension support kicks off. - MIDI engine read-ahead period has been shortened to half than it was since inception--now it's a 500msec cycle. - MIDI clip editor event list gets its due inline editing, for time, note, value/velocity and duration columns, just one double-click away over the target cell ;) - Add-plugin selection dialog position and extent are now remembered across invocations and application sessions (tipping by Frank Neumann). - MIDI clip time-stretching is now made available through the same gestures as audio ones, by just shift+dragging either of the clip edges. - Drag-and-copying plug-in instances (cloning) is now fixed with regard to param
