[ANN] Qtractor 0.6.7 - The Lepton Acid beta release!

[rncbc]

It's alive!

Qtractor 0.6.7 (lepton acid beta) is out!

Release highlights:

* MIDI instrument rendering on audio export (NEW)
* MIDI clip editor view/event criteria persistence (NEW)
* MIDI clip editor resilience on record/overdub (FIX)
* Generic plugin form position persistence (NEW)
* JACK Transport/Timebase master option (NEW)

and yet more tiny lurking critters swatted

Well, the major highlight to this release is in fact this brand new and way long overdue feature, seamlessly integrated to the faithful and regular audio track export function: MIDI track instrument plug-in rendering and mix-down (aka. freeze) is now real, as long their audio output goes onto selected buses, aka. stems, mix-groups, whatever a mix/mastering head would name it! nb. on the (very esquisite) Qtractor arch-model parlance, those are just called "audio output buses" and that ain't gonna change, any time soon, so stop it! A word of caution must be told by now: dedicated (JACK) audio output ports are off-the-grid, so sorry.

Maybe this silently makes a notch towards the DAW epitome, though Qtractor still claims to be just a plain and honest sequencer--with yet another DAW-like feature addition--the same as it ever was.

Nuff said.



Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt framework. Target platform is Linux, where the Jack Audio Connection Kit (JACK) for audio and the Advanced Linux Sound Architecture (ALSA) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio.

Website:
http://qtractor.sourceforge.net

Project page:
http://sourceforge.net/projects/qtractor

Downloads:
http://sourceforge.net/projects/qtractor/files

- source tarball:
qtractor-0.6.7.tar.gz

- source package (openSUSE 13.2):
qtractor-0.6.7-17.rncbc.suse132.src.rpm

- binary packages (openSUSE 13.2):
qtractor-0.6.7-17.rncbc.suse132.i586.rpm
qtractor-0.6.7-17.rncbc.suse132.x86_84.rpm

- wiki (help wanted!):
http://sourceforge.net/p/qtractor/wiki/

Weblog (upstream support):
http://www.rncbc.org

License:
Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

Change-log:
- MIDI clip editor (aka. piano-roll) position, size, and view/event type criteria are now persistent, across session and user preferences application state.
- Generic plugin form widget position is now also preserved across open/save session cycles.
- MIDI clip editor resilience is about to get an improvement, fe. it doesn't close on stopping record/overdub anymore.
- Introducing (JACK) Timebase master setting as an option to Transport mode (cf. View/Options.../General/Transport/Timebase).
- LV2 plug-in MIDI/Event support now slanted for deprecation.
- Spanish (es) translation added, by David Reyes Pucheta.
- It's live: audio track export (cf. Track/Export Tracks/Audio...) has been deeply refactored to finally include MIDI track/instrument plugins rendering (aka. freeze) on selected audio output buses on mix-down. (EXPERIMENTAL)
- MIDI file player now does (N)RPN 14-bit controller events.
- Track properties dialog output bus switch fix/optimization; also fixed multiple DSSI instance reference count on close.
- Fixed for some strict tests for Qt4 vs. Qt5 configure builds.
- German (de) translation update (by Guido Scholz, thanks).


See also:
http://www.rncbc.org/drupal/node/894


Enjoy && keep the fun.
--
rncbc aka. Rui Nuno Capela

[glowrak guy]

Freeze is kool! The thought of long cold nights at the daw, gives me the chills.

[glowrak guy]

Tested the suse rpm version briefly with official nvidia 3D video, loading U-he Diva, Hive, and Filterscape,
and evrything seems fine. Especially nice, is being able to use click-to-front,
and minimize/maximize/raise/lower among the gui's, on a jurassic computer.

If it gets any better, you'll be accused of deflating balls, or bribing FIFA

[danboid]

I'm keen to try qtr's new freeze feature but I've not been able to get qtr (0.6.7 or git) to build against Qt4 under Arch, which now defaults to Qt5.

I've got qtr to build against Qt5 under Arch but qtr crashes as soon as you try adding a plugin so Rui only advises building with Qt4 currently.

I've tried:

export QT_SELECT=4
export ac_qmake=/usr/bin/qmake-qt4
export ac_moc=/usr/bin/moc-qt4
export ac_uic=/usr/bin/uic-qt4
export ac_lupdate=/usr/bin/lupdate-qt4
export ac_lrelease=/usr/bin/lrelease-qt4
export QMAKE=qmake-qt4

./configure --with-qt4=/usr/lib --enable-qt4

and more stuff I don't remember right now. qtr just ain't having qt4 under Arch for me :/

[rncbc]

export QT_SELECT=4

this only makes sense if qtchooser is installed and available.

export ac_qmake=/usr/bin/qmake-qt4
export ac_moc=/usr/bin/moc-qt4
export ac_uic=/usr/bin/uic-qt4
export ac_lupdate=/usr/bin/lupdate-qt4
export ac_lrelease=/usr/bin/lrelease-qt4
export QMAKE=qmake-qt4

this doesn't make much sense to me. where did you come with all that from?

./configure --with-qt4=/usr/lib --enable-qt4

and more stuff I don't remember right now. qtr just ain't having qt4 under Arch for me :/

most of these questions should be addressed to the Arch lists perhaps, whether or how to get the qt4 development environment selected back and over the new qt5 default.

if qtchooser is anyhow available, install it and read its instructions, please. otherwise there must be some other a way to get the qt4 sdk as current default. i just cabn't help you there (

why don't you try also something like the following provided /usr/lib/qt4 directory exists:

Code: Select all

./autogen.sh clean
./autogen.sh
./configure --with-qt4=/usr/lib/qt4
make

?

hth.
cheers

[Joermungand]

danboid wrote:
export ac_qmake=/usr/bin/qmake-qt4
export ac_moc=/usr/bin/moc-qt4
export ac_uic=/usr/bin/uic-qt4
export ac_lupdate=/usr/bin/lupdate-qt4
export ac_lrelease=/usr/bin/lrelease-qt4
export QMAKE=qmake-qt4

this doesn't make much sense to me. where did you come with all that from?

From the qtractor-svn PKGBUILD.

The thing is, the SVN version off SourceForge builds just fine for me with or without these settings. That is, (without them) it builds just fine with Qt5. However, whether it’s built against Qt4 or Qt5, it still hangs on errors while parsing lv2 plugins (which I don’t think is related to Qt). Is there a way to bypass that (just to be able to get past that step)?

[funkmuscle]

I'm keen to try qtr's new freeze feature but I've not been able to get qtr (0.6.7 or git) to build against Qt4 under Arch, which now defaults to Qt5.

I've got qtr to build against Qt5 under Arch but qtr crashes as soon as you try adding a plugin so Rui only advises building with Qt4 currently.

I've tried:

export QT_SELECT=4
export ac_qmake=/usr/bin/qmake-qt4
export ac_moc=/usr/bin/moc-qt4
export ac_uic=/usr/bin/uic-qt4
export ac_lupdate=/usr/bin/lupdate-qt4
export ac_lrelease=/usr/bin/lrelease-qt4
export QMAKE=qmake-qt4

./configure --with-qt4=/usr/lib --enable-qt4

and more stuff I don't remember right now. qtr just ain't having qt4 under Arch for me :/

it's in the Arch repo now!

[rncbc]

The thing is, the SVN version off SourceForge builds just fine for me with or without these settings.

what SVN repo are you sourcing? it's a GIT repo for quite some time now. still on SF.net though.

That is, (without them) it builds just fine with Qt5. However, whether it’s built against Qt4 or Qt5, it still hangs on errors while parsing lv2 plugins (which I don’t think is related to Qt). Is there a way to bypass that (just to be able to get past that step)?

you saying it hang on run-time or compile-time? if on run-time, check whether /usr/lib64 is symlinked to /usr/lib which is certain to hose the the stderr/out with lv2 duplicates error messages...

you can sort of workaround by doing either or both of the following:
a. set View/Options.../General/Options/Capture standard output OFF;
b. set View/Options.../Plugins/Paths/LV2 explicitly to. ~/.lv2 , /usr/local/lib/lv2 and /usr/lib/lv2; (nb. qtractor defaults to both .../lib64 and .../lib on x64 systems, thus the duplicate error explosion when those are tied together as symlinked--they shouldn't! why is that so on Arch? beats me!).

hth.
cheers

[danboid]

funkmuscle:

Thanks for the notice! I've uninstalled my qt5 build and installed the latest repo build which is working fine. I can't believe it took so long to get into the Arch repos!

Rui:

I love the new 'freeze' mode! qtr has just gotten MUCH more usable with 0.6.7 for those who want to use MIDI plugins. Great work!

However, I thought qtr was supposed to support sub-plugins now? I'm only seeing Zebra and no Zebralette.

[rncbc]

However, I thought qtr was supposed to support sub-plugins now? I'm only seeing Zebra and no Zebralette.

to get vst-shell plugins aka. sub-plugins discovered you have to turn View/Options.../Plugins/Experimental/Dummy VST plugin scan OFF.

however, be careful and take notice of the "recommended" warning : some lurking vst plugin may still be around on the search paths and mis-behaves upon the non-dummy scan and might cause random crashes afterwards--yeah, it doesn't happen on any given moment, it just happens when you sure don't expect---don't call me for the rescue

hth.
cheers

[danboid]

Thanks Rui!

[funkmuscle]

funkmuscle:

Thanks for the notice! I've uninstalled my qt5 build and installed the latest repo build which is working fine. I can't believe it took so long to get into the Arch repos!

.

I've been noticing that lately with audio programs.. It's like if the Arch devs don't want folks using it for audio.. I know I'm worng but it feels like it because they use to be the first to have stuff in the repos.

[glowrak guy]

Blame the IOGG cartel. Apps for internet, office, games, and graphics come first,
then if there is time, throw a bone to the poor hungry musicians

[danboid]

However, I thought qtr was supposed to support sub-plugins now? I'm only seeing Zebra and no Zebralette.

to get vst-shell plugins aka. sub-plugins discovered you have to turn View/Options.../Plugins/Experimental/Dummy VST plugin scan OFF.

however, be careful and take notice of the "recommended" warning : some lurking vst plugin may still be around on the search paths and mis-behaves upon the non-dummy scan and might cause random crashes afterwards--yeah, it doesn't happen on any given moment, it just happens when you sure don't expect---don't call me for the rescue

hth.
cheers

Could you clarify this a bit more please Rui?

What is a dummy VST plugin? I presume its a different thing from a VST plugin that contains sub-plugins but maybe I'm wrong? Is a sub-plugin a dummy plugin?

How can we scan for and detect dummy plugins or plugins that may cause issues when we disable the dummy plugin scanning?

Will you not officially support sub-plugins in qtractor?

[rncbc]

What is a dummy VST plugin? I presume its a different thing from a VST plugin that contains sub-plugins but maybe I'm wrong? Is a sub-plugin a dummy plugin?

How can we scan for and detect dummy plugins or plugins that may cause issues when we disable the dummy plugin scanning?

Will you not officially support sub-plugins in qtractor?

a dummy-plugin is kind of a a stub for each one of the library shared objects files (.so) that are found across the search path scan; for each library file that is found, it makes it a generic so called "dummy-plugin" instance filename, each one faking 1 MIDI input and stereo (2 channels) audio inputs/outputs .

this dummy scan is/was the safest way to scan for VST plugins that doesn't cope with actual open/load and close/unload in quick succession (aka. real non-dummy scan process); historically, many JUCE based VSTs were prone to crash and lock-up the host that eg. doesn't open their GUI editor immediately on load, something that qtractor doesn't do ever, especially while scanning on discovery--this might not be an issue any more for most recent JUCE-plugin builds, but it takes just one old leftover still around to doom and compromise it all.

now, VST-shell (sub-)plugins can only be discovered if its library object (.so) is actually loaded up and gone through its run-time programmatic interface, something that is simply skipped while on a dummy-scan, as explained before.

besides, the dummy-scan is just an user safety option rather than an official stance against VST sub-plugins or whatever.

hth.
cheers