I second Rui's plug of qtractor -- it is a great LV2 host and a nice way of easily loading up whatever environmental configurations you might need in association with a particular track. The "save your config with a project" integration aspects might sound trivial "on paper" but it makes a huge difference if you don't like wasting lots of time remembering how to get back to the configuration needed to produce a given sound. I look forward to trying out Ardour3's MIDI support; ardour2's interface, though daunting at first, is very responsive&predictable and refined. Rosegarden, as well, has the feel of something that people have actually worked with and refined for a long time. Qtractor does this too, by virtue of "feeling" like Cakewalk Pro Audio, which is what I'm used to in the first place. What I don't understand is why there isn't more overt collaboration and code-sharing between the different DAWs, because ultimately, I find myself wishing I could mix-and-match a "module" of functionality from qtractor with another module of functionality from ardour and another from rosegarden. Some kind of abstract non-destructive-editing core that can be "skinned" by Gtk, or Qt, or even in the browser ( http://news.cnet.com/8301-19882_3-10354268-250.html ). Of course, the "core" would all be with tight C/C++, thread-safe and smartly-locked, locally-memory-managed; the "skinning" and "gluing" would be in a STM-capable interpreted language that prevents you from needing to think about GUI-update locking issues any more than you'd think about using a predefined type declaration for a variable... Potentially, multithread access to shared memory data-structures seems to be the cause of hard-to-reproduce error messages coming out of Qt-based apps (see also https://bugs.kde.org/show_bug.cgi?id=240391 ): gnulem-109-~/Documents> qtractor *** glibc detected *** qtractor: corrupted double-linked list: 0x00000000012ab6a0 *** ^C You may never see these errors until you run these apps on a fast quad-core machine. For Qtractor -- my hunch of the day -- check for simultaneous access to the "inputs" and "outputs" configurations; after loading several projects or activating "track->inputs" "track->outputs" or the "outputs" and "inputs" buttons in the mixer (all of which pop up the "Connections" window)... do this a few times and eventually your midi devices disappear in the gui. You have to go to the "Connections" window's option-menu and select "(All)" or reselect the current option in order to refresh the display. Something's getting "clobbered" in the midi or audio connections listings each time you load a new .qtr or .qtt file... and this is an error that recurs more quickly on a fast quad-core than a slower dual-core. ... makes me think i was right on track with all my comments about clojure, garbage-collection, and software transactional management :-) ... i think i'll need a supercomputer to run "valgrind --tool=helgrind qtractor" ... Niels http://nielsmayer.com PS: Just so that Rui doesn't feel like I'm picking on him, this is my other favorite error message of the week ( https://bugzilla.redhat.com/show_bug.cgi?id=600713 ) gnulem-119-~/Documents> rosegarden Setting graphics system for Qt 4.5+ to: raster [...] Warning: Composition::~Composition() with 3 observers still extant Observers are: 0x29e1ac0 [N10Rosegarden19SegmentParameterBoxE] 0x2a34df0 [N10Rosegarden17TrackParameterBoxE] 0x2ed5f80 [N10Rosegarden20CompositionModelImplE] *** glibc detected *** rosegarden: double free or corruption (out): 0x00007f829c223ba0 *** ======= Backtrace: ========= /lib64/libc.so.6[0x38e7e74ac6] /usr/lib64/dssi/calf.so(_ZN12calf_plugins14ladspa_wrapperINS_23compressor_audio_moduleEED1Ev+0x37)[0x7f82a4130d07] /lib64/libc.so.6(exit+0xe2)[0x38e7e35b82] /lib64/libc.so.6(__libc_start_main+0x104)[0x38e7e1eb24] rosegarden[0x43cfd9] PPS: Ardour's Gtk doesn't seem to be as fragile since quitting only produces the following, without coredumping :-) .... (ardour-2.8.7:29963): Gtk-CRITICAL **: gtk_box_pack: assertion `child->parent == NULL' failed Session writable based on /home/npm/Music/yoshimidoublearpeggiator/ (ardour-2.8.7:29963): Gtk-CRITICAL **: gtk_box_pack: assertion `child->parent == NULL' failed ...

On 06/05/2010 07:19 PM, Niels Mayer wrote: this is most likely one hideous memory corruption bug, runaway memwrite, double or even triple memleak. whatever. do not (ever) rule out my sloppy coding habits. i do have a quad, where is my primary devel host, intel q8200 though, maybe not the fastest, but still find some of those reported crashes very hard to reproduce. indeed. valgrind may help but it may get you also bored to death even on the fastest of the machines, unless you can reproduce the crashes in a finite, consistent and determined number of steps. i've been there i've done that and still chose to step over and run forward :) cheers -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

I think I figured out what was causing the recent odd-behavior in qtractor (which has otherwise been stable enough to use as my main DAW). The problem was operator error and not qtractor. I had recently enabled the high-res timer and had accidentally set "View->Options->MIDI->Playback->Queue timer (resolution)" to "PCM Playback 1-0-0. (slave)" instead of ""PCM Playback 2-0-0. (slave)"... this caused the MIDI to go all wonky, and caused various freezes when making changes to the MIDI configuration. The problem is that jack is not talking to "playback 1-0-0" it is running on "playback 2-0-0" ... I finally figured this one out because qtractor would occassionally start rolling (as if play got clicked) simply by starting up the program. That's when I started investigating the value of the midi queue timer and found the erroneous setting. Previously, in thread "Is ALSA using hrtimer?" I asked about these settings... I guess I found out the hard way what happens when you set to the wrong value! For those that have an HRtimer, should the queue timer be set to "HR timer (1000000000 hz)"? "(default)" or slaved to the specific soundcard that jack is managing? http://linuxaudio.org/mailarchive/lau/2010/5/31/169505 .................. BTW, now that I've enabled hr timer, I notice that qtractor 's View->Options->MIDI->Playback has an entry for "Queue timer (resolution): [ (default), system timer (1000 Hz), HR timer (1000000000 hz), PCM Playback 0-0-0. (slave), PCM Playback 0-0-1 (slave), ... ]" What happens if I use "HR timer" instead of "(default)" or a specific PCM slave, when recording/playing back audio clips ? Does "PCM playback (slave)" mean the audio sample-clock is sync'd to the midi clock, or vice-versa? And if snd-hrtimer is available, wouldn't both audio and midi be using the same clock? (per Grant's comment ''CONFIG_SND_HRTIMER says: "ALSA uses the hrtimer as a precise timing source. The ALSA sequencer code also can use this timing source."'' ) W/r/t qtractor, does (default) "do the right thing" or should I be choosing a specific option based on use? I guess I'll find out... ................... -- Niels http://nielsmayer.com PS: to prevent this error in the future, would it be possible to suppress incorrect values from the choices presented for "queue timer (resolution)" ... for example don't allow user to select "PCM Playback 0-0-0 (slave) if that is not the device being managed by Jack.

On 06/06/2010 07:35 AM, Niels Mayer wrote: afaict, this midi queue timer resolution deals _only_ with the specific timer assigned to the alsa sequenecer (midi) queue; it has nothing to do nor messes with the timing source chosen in jackd -c. rationale goes like that you should use the highest resolution timer available (snd-hrtimer). anyhow, as far as qtractor or rosegarden goes, timer selection should be carried out fundamentally in an attempt to minimize jitter between the audio (jack) and midi (alsa-seq) streams, allowing a much better and precise drift compensation between the two clocks (audio's and midi's). bottom line goes about to use the highest resolution timer your system allows you to. it is not that clear to me that for best results both jack and alsa-seq clocks should be of the same source. jack/audio time source should be a most regular one whereas the alsa-seq/midi timer should be of the highest resolution (granularity) possible. nb. if using the vanilla stock kernel, the default system timer is a extremely poor resolution one (250hz) so that using a pcm slave timer is the next best choice, if hrtimer is not found available, that is. the "(default)" system timer has been doing the right thing here for ages, but i do always care to have the system timer resolution set on 1000hz (custom kernel). however, i remember some mixed reports that the hrtimer is a scarce system resource, prone to exhausting and freezing lock-ups. maybe that's just a recurring myth by now, given the latest and greatest kernels. usually ymmv :) yep. try && tell -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On Sat, Jun 5, 2010 at 1:19 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote: this is a little misguided. i can only speak to the ardour case, but in the ardour case, we already do the "skin the backend with GTK" approach. libardour, the backend of ardour, makes no reference to GTK and no direct reference to any GUI at all (it can't, because we want it to be usable with no GUI, multiple GUIs, 1 GUI and 1 MIDI UI, 1 GUI and 1 OSC UI or any combination you can imagine). but what this means in practice is that more than 75% of the code of ardour *IS* the "skin". every person who has ever said "why can't we just add a Qt GUI for Ardour doesn't seem to grasp that in some very real sense, Ardour *IS* a GTK program much more than it is a realtime, multichannel, multitrack, nonlinear, nondestructive DAW (in terms of how much code there is that supports the GUI versus the backend). i am fairly sure that this is true of QTractor and Rosegarden also (substituting Qt for GTK, obviously). furthermore, even our choice of backend API (for example, our use of boost:: or sigc:: signals) has a fairly major impact on any user of libardour. i recently switched ardour3 from sigc::signal as the main way that the backend notifies interested parties of various changes and started using boost::signals2 instead. they are conceptually quite similar, but it still took a pretty huge effort to make the switch. and yet this was a relatively small change in a relatively unimportant aspect of the backend. even the *concepts* represented by the backend are important. the model that rosegarden has to represent tempo & meter is completely different from the one ardour has. even code level issues, trying to fit something from RG into Ardour (or vice versa) that has to tackle tempo & meter would be incredibly hard because of the different data structures and metaphors used in each program. i assume you've filed a bug report on this, and/or verified that the problem still exists in ardour 2.8.9 ? ...

Quoting Ken Restivo <ken(a)restivo.org>rg>: Nope, A2 works fine with LV2, you just have to have lv2-core and slv2 installed, and possibly pass LV2=1 (it is erroneously described otherwise in the documentation) to the scons build line. - Peder

On Sat, Jun 05, 2010 at 10:41:41PM +0200, Peder Hedlund wrote: g++ -o libs/ardour/globals.os -c -Woverloaded-virtual -DGTK_NEW_TOOLTIP_API -DPACKAGE=\"libardour2\" -DLIBSIGC_DISABLE_DEPRECATED -DDATA_DIR=\"/usr/local/share\" -DMODULE_DIR=\"/usr/local/lib64\" -DVAMP_DIR=\"/usr/local/lib64/ardour2/vamp\" -DCONFIG_DIR=\"/usr/local/etc\" -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_JACK_CLIENT_OPEN -DHAVE_JACK_RECOMPUTE_LATENCIES -DHAVE_JACK_VIDEO_SUPPORT -DHAVE_JACK_PORT_ENSURE_MONITOR -DHAVE_WORDEXP -DHAVE_SYS_VFS_H -DHAVE_LV2 -O3 -fomit-frame-pointer -ffast-math -fstrength-reduce -pipe -DARCH_X86 -mmmx -msse -mfpmath=sse -DUSE_XMMINTRIN -DBUILD_SSE_OPTIMIZATIONS -DUSE_X86_64_ASM -Wall -DHAVE_LIBLO -Ilibs -DENABLE_NLS -DHAVE_SLV2 -D_REENTRANT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Ilibs -pthread -DUSE_RUBBERBAND -fPIC -Ilibs/pbd -I/usr/include/glib-2.0 -Ilibs/surfaces/control_protocol -Ilibs/midi++2 -Ilibs/vamp-sdk -Ilibs/sigc++2 -Ilibs/glibmm2 -I/usr/lib/glib-2.0/include -Ilibs/ardour -Ilibs/rubberband -I/usr/include/libxml2 -I/usr/local/include libs/ardour/globals.cc In file included from /usr/local/include/slv2/slv2.h:29, from libs/ardour/ardour/lv2_plugin.h:34, from libs/ardour/ardour/plugin_manager.h:32, from libs/ardour/globals.cc:62: /usr/local/include/slv2/plugininstance.h:80: error: expected ‘,’ or ‘...’ before ‘*’ token In file included from /usr/local/include/slv2/pluginuiinstance.h:27, from /usr/local/include/slv2/slv2.h:31, from libs/ardour/ardour/lv2_plugin.h:34, from libs/ardour/ardour/plugin_manager.h:32, from libs/ardour/globals.cc:62: /usr/local/include/slv2/lv2_ui.h:277: error: expected ‘,’ or ‘...’ before ‘*’ token In file included from /usr/local/include/slv2/slv2.h:31, from libs/ardour/ardour/lv2_plugin.h:34, from libs/ardour/ardour/plugin_manager.h:32, from libs/ardour/globals.cc:62: /usr/local/include/slv2/pluginuiinstance.h:67: error: expected ‘,’ or ‘...’ before ‘*’ token In file included from libs/ardour/ardour/plugin_manager.h:32, from libs/ardour/globals.cc:62: libs/ardour/ardour/lv2_plugin.h:72: error: ISO C++ forbids declaration of ‘LV2_Feature’ with no type libs/ardour/ardour/lv2_plugin.h:72: error: expected ‘;’ before ‘*’ token libs/ardour/ardour/lv2_plugin.h:74: error: expected `;' before ‘std’ libs/ardour/ardour/lv2_plugin.h:119: error: ISO C++ forbids declaration of ‘LV2_Feature’ with no type libs/ardour/ardour/lv2_plugin.h:119: error: expected ‘;’ before ‘*’ token libs/ardour/ardour/lv2_plugin.h:135: error: ‘LV2_Feature’ does not name a type libs/ardour/ardour/lv2_plugin.h:136: error: ‘LV2_Feature’ does not name a type scons: *** [libs/ardour/globals.os] Error 1 scons: building terminated because of errors. It's been a couple months, but this is what happened last I tried. -ken

On Sat, 5 Jun 2010, Peder Hedlund wrote: Ok, A2 lets me load an LV2 instrument... ...but then how do I use it? Where do I connect to its MIDI port? -gabriel

On Sat, 5 Jun 2010, Paul Davis wrote: Thanks! I thought that was the case. ...and A3, with MIDI support (and a sequencer?) /does/ deliver MIDI to instruments. Right? -gabriel

On 06/05/2010 09:19 PM, Ken Restivo wrote: i've used ardour2 with the calf and lv2fil lv2 plugins for many months. iiuc, calf uses the gtk gui, whereas lv2fil implements a python ui using the external ui extension. moreover, the lv2 variants of steve harris' swh plugins work in ardour (at least those that i've tried so far). some of those require other minor extensions, which ardour supports, too. the tricky part is to get the rdf and lv2 related dependencies right. either you try the distro devel packages (only if it's a pretty recent distro), or check out drobilla's tree. in the past, it has either compiled flawlessly (most of the time), or exploded in my face right away, in which case waiting a few days or downgrading to a slightly earlier revision fixed things.