5 Oct
2011
5 Oct
'11
10:09 a.m.
Howdy,
Summer is now long gone, obviously fall has already begun. As winter
looms on the horizon the year steadily marches into its due end. (oh
crap!...)
Today marks the day of this second public release while on the TYOQA
age. It also marks yet another birthday of mine. One more year's gone,
one less to go. Be happy! I hope you'd like my party as soon you get
over from yesterday's bitten fruit showtime.
Now's the time...
Qtractor 0.5.1 (bravo yankee) is out!
Yes, it's "bravo" alright, not "beta" nor anything else. Despite
any
previous existing codename. Now, it's all dumb-down easy to predict any
next release codenames, a matter of convergence and fact that just
chalks one less of a burden on me :)
Believe it or not, this is the best and, allegedly, the most stable
release ever. Ain't them all? ;)
Release highlights:
* Linked (aka. ref-counted) audio/MIDI clips (NEW)
* Aux-Send pseudo-plugin (NEW)
* Direct-access plugin parameter slider (NEW)
* MIDI file player (NEW)
* Automatic time-stretching of audio clips on tempo-map changes (FIX)
* Improved native Linux VST support (FIX)
* Improved JACK-Session support (FIX)
* Improved generic plugin form (FIX)
* MIDI-fx plugin support (NEW)
* Audio bus/ports auto-connect option (NEW)
* First translation call (Czech) (NEW)
Cheers!
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.5.1.tar.gz
- source package (openSUSE 11.4):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.1-4.rncbc.suse114.sr…
- binary packages (openSUSE 11.4):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.1-4.rncbc.suse114.i5…
http://downloads.sourceforge.net/qtractor/qtractor-0.5.1-4.rncbc.suse114.x8…
- from the paleolithic shelves: user manual:
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
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:
- More LADISH support: SIGTERM signal is now trapped for graceful
application close.
- Improved paste-repeat snap precision when dealing with large repeat
counts.
- Czech (cs) translation added, by Pavel Fric.
- Added a few snap-to-beat divisors (unusual Beat/5, Beat/7, Beat/9 and
Beat/10) for completeness sake.
- Such a simple change of mind with a visual twist: the "A" track
automation button/menu has now been
- moved to the right-most, as it belongs ;)
- Auto-connection of dedicated audio outputs is now optional for default
audio master bus, metronome, player and MIDI instrument plugin dedicated
audio outputs.
- Finally, after a pitiful large brain-dead period, generic plugin forms
are now showing all possible controllable plugin parameters featuring a
paged, tabbed dialog, whenever applicable.
- Special hack/fix for JUCE based native VST plugins, which are the most
actually found with a GUI editor, skipping explicit shared library
unloading and thus avoiding some mysterious crashes on session close
and/or application exit.
- Support for MIDI-fx plugins (native VST and/or LV2) is now implemented
and functional (intra-chain only).
- Instrument plugin bank/program selection was found broken or dead in
the water, specially on VSTi, now finally fixed again.
- VST plugin parameter value display on generic form is now back in
business (were dead regarding value changes).
- All plugin's provided GUI editors are now honored by being popped up
first, instead of the usual but good old generic plugin form.
- Long overdue implementation of a dedicated MIDI file player is now
accessible from the MIDI files widget; one can play the whole SMF or
just a single track or channel.
- Update to a newer VeSTige header, probably fixing an old 32 vs. 64 bit
mismatch.
- Avoid JACK session filenames/paths to be ever shown; also avoid all
buses ports (re)connections when JACK sessions are (re)loaded, given the
fact that session management will take care of just that; more also,
untitled/default session names are now also picked up to match current
LADISH project name, obviously given by LADISH_PROJECT_NAME environment
variable, whenever present (as suggested by Nedko Ardaunov).
- Paste-repeat floating selection has been fixed (was showing only the
last repeated selection).
- Coherence of tempo changes on audio and MIDI clips, whether automatic
time-stretching is in effect, has been slightly improved, hopefully fixed.
- Bold attempt to get linked (aka. ref-counted) audio and MIDI clips
into practice (EXPERIMENTAL).
- Main track view now showing all clips above the grid.
- Added support for both new and older (deprecated URI) lv2_external_ui
extension (by Nedko Ardaunov).
- Following yet another great idea, and implementation, by Holger
Dehnhardt, who already brought us the new aux-send insert plugin, thanks
again, the so-called direct access control option is now featured for
any plugin parameter right from plugin listings eg. mixer strips.
- General resource consumption and management has been slightly
improved, due to internal buses allocation optimization.
- Fixed nasty crash-bug that was severely affecting all sessions that
had at least one insert (pseudo-)plugin on any audio input bus.
- All automation curve nodes are now relocated whenever disparate
session sample-rate is detected on load.
- New aux-send/insert pseudo-plugin is now introduced, allowing to route
any track audio output to any other audio output bus besides the nominal
one -- thanks to an original implementation from Holger Dehnhardt.
- New immediate edit/loop-range settings from current clip extents,
accessible on the main menu (Clip/Range Set, Loop Set) and from MIDI
clip editor menu as well (File/Range Set, Loop Set).
- MIDI Names XML files (*.midnam) may now be imported into MIDI
instrument definitions. (EXPERIMENTAL)
- Avoid cursor reset while editing MIDI events list (fixes bug #3380259,
reported by Frank Neumann).
- Just some typos fixing (patch #3378382 by c-korn).
- Track view automation curve editing mode has been slightly fixed, now
allowing for other previously existing point-and-click mouse operations.
- Default automation curve mode is now preserved (following a suggestion
by Alexandre Prokoudine, thanks).
Enjoy!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
5 Oct
5 Oct
10:52 a.m.
On Wed, 05 Oct 2011 09:09:43 +0100, Rui Nuno Capela wrote
Howdy,
Summer is now long gone, obviously fall has already begun. As winter
looms on the horizon the year steadily marches into its due end. (oh
crap!...)
Today marks the day of this second public release while on the TYOQA
age. It also marks yet another birthday of mine. One more year's
gone, one less to go. Be happy! I hope you'd like my party as soon
you get over from yesterday's bitten fruit showtime.
Now's the time...
Qtractor 0.5.1 (bravo yankee) is out!
Yes, it's "bravo" alright, not "beta" nor anything else. Despite
any
previous existing codename. Now, it's all dumb-down easy to predict
any next release codenames, a matter of convergence and fact that
just chalks one less of a burden on me :)
Believe it or not, this is the best and, allegedly, the most stable
release ever. Ain't them all? ;)
Thanks for the work!
I just updated my (svn) build. Did I miss something or is there still
no jack midi support?
Cheers, Ralf Mattes
--
R. Mattes -
Hochschule fuer Musik Freiburg
rm(a)inm.mh-freiburg.de
11:14 a.m.
On 10/05/2011 09:52 AM, R. Mattes wrote:
On Wed, 05 Oct 2011 09:09:43 +0100, Rui Nuno Capela
wrote
no, you didn't miss anything. there's still no jack-midi support.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Qtractor 0.5.1 (bravo yankee) is out!
Thanks for the work!
I just updated my (svn) build. Did I miss something or is there still
no jack midi support?
12:38 p.m.
On Wed, 05 Oct 2011 09:09:43 +0100
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
Howdy,
Summer is now long gone, obviously fall has already begun. As winter
looms on the horizon the year steadily marches into its due end. (oh
crap!...)
Today marks the day of this second public release while on the TYOQA
age. It also marks yet another birthday of mine. One more year's
gone, one less to go. Be happy! I hope you'd like my party as soon
you get over from yesterday's bitten fruit showtime.
Now's the time...
Qtractor 0.5.1 (bravo yankee) is out!
Yes, it's "bravo" alright, not "beta" nor anything else. Despite
any
previous existing codename. Now, it's all dumb-down easy to predict
any next release codenames, a matter of convergence and fact that
just chalks one less of a burden on me :)
Believe it or not, this is the best and, allegedly, the most stable
release ever. Ain't them all? ;)
Hi Rui, it's allways fun reading your release announcements :)
what exactly do these two mean?
* Linked (aka. ref-counted) audio/MIDI clips (NEW)
* MIDI-fx plugin support (NEW)
can't wait to play with the new toys!
and happy birthday of course,
renato
6:40 p.m.
On 10/05/2011 11:36 AM, Renato wrote:
On Wed, 05 Oct 2011 09:09:43 +0100
Rui Nuno Capela<rncbc(a)rncbc.org> wrote:
previously on qtractor, each clip had a complete independent data object
(buffer) from each other. now the clip data buffer is shared for all
clips in a track that refer to the same filename, offset and length.
for audio clips this can be a huge resource optimization. for midi clips
it also means that editing or changing events on one of the "linked"
clips will also affect all the others that refer to the same midi
sequence (ie. same midi file, channel, offset and length, of course).
in practice, it means that all copy&paste-repeated clips will refer to
very same internal data buffer/sequence. you change one, you'll change
all. got that?
Qtractor 0.5.1 (bravo yankee) is out!
what exactly do these two mean?
> * Linked (aka. ref-counted) audio/MIDI clips (NEW) > * MIDI-fx plugin support (NEW)
midi-fx plugins are that special kind that takes midi processing
exclusively. they take midi input, eventually transform it and throw the
result as midi output for consumption by the next plugin in chain, which
might be another midi-fx or ultimately a midi-instrument one (often a
synth plugin). there's no audio signal involved. only midi going in,
thru and out. eg. pizmidi plugin collection (vst). cf. audio-fx plugins,
where audio is the only processing subject (eg. ladspa)
can't wait to play with the new toys!
and happy birthday of course,
thanks
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
6:56 p.m.
On Wed, 05 Oct 2011 17:40:00 +0100
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
cool stuff!
cheers
renato
On 10/05/2011 11:36 AM, Renato wrote:
yes, that sounds good
On Wed, 05 Oct 2011 09:09:43 +0100
Rui Nuno Capela<rncbc(a)rncbc.org> wrote:
previously on qtractor, each clip had a complete independent data
object (buffer) from each other. now the clip data buffer is shared
for all clips in a track that refer to the same filename, offset and
length.
for audio clips this can be a huge resource optimization. for midi
clips it also means that editing or changing events on one of the
"linked" clips will also affect all the others that refer to the same
midi sequence (ie. same midi file, channel, offset and length, of
course).
in practice, it means that all copy&paste-repeated clips will refer
to very same internal data buffer/sequence. you change one, you'll
change all. got that? Qtractor 0.5.1 (bravo yankee) is out!
what exactly do these two mean?
> * Linked (aka. ref-counted) audio/MIDI clips (NEW) > * MIDI-fx
plugin support (NEW)
midi-fx plugins are that special kind that takes midi processing
exclusively. they take midi input, eventually transform it and throw
the result as midi output for consumption by the next plugin in
chain, which might be another midi-fx or ultimately a midi-instrument
one (often a synth plugin). there's no audio signal involved. only
midi going in, thru and out. eg. pizmidi plugin collection (vst). cf.
audio-fx plugins, where audio is the only processing subject (eg.
ladspa) 
7:33 p.m.
Am 05.10.2011 18:40, schrieb Rui Nuno Capela:
++
:-)
On 10/05/2011 11:36 AM, Renato wrote:
Nice nice and useful too but then again.... what if I copy/paste a
drum-clip and want to add a crash-hit to it whithout having that crash
on every clip the copy has derived from? Is there some option such as
"right-klick/make new individual clip from copy"?
On Wed, 05 Oct 2011 09:09:43 +0100
Rui Nuno Capela<rncbc(a)rncbc.org> wrote:
previously on qtractor, each clip had a complete independent data object
(buffer) from each other. now the clip data buffer is shared for all
clips in a track that refer to the same filename, offset and length.
for audio clips this can be a huge resource optimization. for midi clips
it also means that editing or changing events on one of the "linked"
clips will also affect all the others that refer to the same midi
sequence (ie. same midi file, channel, offset and length, of course).
in practice, it means that all copy&paste-repeated clips will refer to
very same internal data buffer/sequence. you change one, you'll change
all. got that? Qtractor 0.5.1 (bravo yankee) is out!
what exactly do these two mean?
> * Linked (aka. ref-counted) audio/MIDI clips (NEW) > * MIDI-fx plugin support (NEW)
midi-fx plugins are that special kind that takes midi processing
exclusively. they take midi input, eventually transform it and throw the
result as midi output for consumption by the next plugin in chain, which
might be another midi-fx or ultimately a midi-instrument one (often a
synth plugin). there's no audio signal involved. only midi going in,
thru and out. eg. pizmidi plugin collection (vst). cf. audio-fx plugins,
where audio is the only processing subject (eg. ladspa)
> can't wait to play with the new toys!
>
> and happy birthday of course,
thanks
6 Oct
6 Oct
12:11 p.m.
@Hartmut Noack
(http://www.spinics.net/lists/linux-audio-users/msg80491.html)
On Wed, 05 Oct 2011 17:40:00 +0100, Rui Nuno Capela
wrote:
you'll have to pick the clip in question, the one you wish to unlink or
detach, and from the midi editor window (aka. piano-roll) you should
save it with a brand new midi filename (ie. File/Save As...)
maybe this could go as an "one-click" procedure, like you suggest, as a
new clip context-menu entry: "Unlink" or "Detach" or whatever:).
noted.
cheers
ps. it's sad i'm not receiving any posts from
linux-audio-user(a)lists.linuxaudio.org, although the ones i send to seem
to get through alright to the list (cf.
http://www.spinics.net/lists/linux-audio-users/); i've just confirmed
that 198.82.152.114 is currently blacklisted on dnsbl.sorbs.net just by
reading my postfix maillog. maybe this is affecting other users as bad,
so i'll ask for you to reply to my own address too (ie. reply all). hyu.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 10/05/2011 11:36 AM, Renato wrote:
Nice nice and useful too but then again.... what if I copy/paste a
drum-clip and want to add a crash-hit to it whithout having that
crash
on every clip the copy has derived from? Is there some option such as
"right-klick/make new individual clip from copy"? On Wed, 05 Oct 2011 09:09:43 +0100
Rui Nuno Capela<rncbc(a)rncbc.org> wrote:
previously on qtractor, each clip had a complete independent data
object (buffer) from each other. now the clip data buffer is shared
for all clips in a track that refer to the same filename, offset and
length.
for audio clips this can be a huge resource optimization. for midi
clips it also means that editing or changing events on one of the
"linked" clips will also affect all the others that refer to the
same
midi sequence (ie. same midi file, channel, offset and length, of
course).
in practice, it means that all copy&paste-repeated clips will refer
to very same internal data buffer/sequence. you change one, you'll
change all. got that?
Qtractor 0.5.1 (bravo yankee) is out!
what exactly do these two mean?
> * Linked (aka. ref-counted) audio/MIDI clips (NEW) 
12:41 p.m.
On 06.10.2011 14:11, Rui Nuno Capela wrote:
Do linked clips stand out visually somehow? I think it would make sense
to make the link easily discoverable - say with color, labeling etc.
Also, in addition to (or instead of) the Unlink/Detach option it would
be nice if the program just asked the user who attempts to change a
linked clip (or save a linked clip that has been changed) whether he/she
wants to change all the related clips or just this one.
Regards,
Artem Vakhitov
Nice nice and
useful too but then again.... what if I copy/paste a
drum-clip and want to add a crash-hit to it whithout having that crash
on every clip the copy has derived from? Is there some option such as
"right-klick/make new individual clip from copy"?
you'll have to pick the clip in question, the one you wish to unlink or
detach, and from the midi editor window (aka. piano-roll) you should
save it with a brand new midi filename (ie. File/Save As...)
maybe this could go as an "one-click" procedure, like you suggest, as a
new clip context-menu entry: "Unlink" or "Detach" or whatever:).
noted.
12:46 p.m.
Hey Rui!
Thanks a lot for implementing the clip thing - I remember asking for that
myself a long time ago )
Louigi.
4:27 p.m.
On Thu, 6 Oct 2011 14:46:29 +0400, Louigi Verona
<louigi.verona(a)gmail.com> wrote:
Hey Rui!
Thanks a lot for implementing the clip thing - I remember asking for
that myself a long time ago )
question is, does it work now as you asked/wanted back then?
:)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
5:29 p.m.
Am 06.10.2011 16:27, schrieb Rui Nuno Capela:
On Thu, 6 Oct 2011 14:46:29 +0400, Louigi Verona
<louigi.verona(a)gmail.com> wrote:
As far as I am concerned I see it as a remarkable improvement. It brings
some of the virtues of a loop-oriented sequencer I sometimes missed in
Qtractor.
To detach a clip from its siblings by giving it a new name makes perfect
sense to me still.... it would be nice to have some automatism that
simply iterates the filename. Some people feel a disturbance in the
force, if they have to switch from editing notes in a pianoroll to
typing filenames ;-)
best regards HZN
Hey Rui!
Thanks a lot for implementing the clip thing - I remember asking for
that myself a long time ago )
question is, does it work now as you asked/wanted back then?
:)
8 Oct
8 Oct
3:16 p.m.
On Thu, Oct 6, 2011 at 11:29 AM, Hartmut Noack <zettberlin(a)linuxuse.de> wrote:
Am 06.10.2011 16:27, schrieb Rui Nuno Capela:
Yes yes yes. This is the worst "feature" of QTractor. I don't give a
$%^& what the filename of an individual clip is, and I don't want to
be interrupted to think about where on disk the file should be stored.
Stash it in a per-session directory, or a "clip library" or whatever.
Don't make me think about that mess I call my home directory.
DISCLAIMER: I haven't used qtractor in a while; I assume it still
works this way. If not, someone tell me to shut up.
On Thu, 6 Oct 2011 14:46:29 +0400, Louigi Verona
<louigi.verona(a)gmail.com> wrote:
As far as I am concerned I see it as a remarkable improvement. It brings
some of the virtues of a loop-oriented sequencer I sometimes missed in
Qtractor.
To detach a clip from its siblings by giving it a new name makes perfect
sense to me still.... it would be nice to have some automatism that simply
iterates the filename. Some people feel a disturbance in the force, if they
have to switch from editing notes in a pianoroll to typing filenames ;-) Hey Rui!
Thanks a lot for implementing the clip thing - I remember asking for
that myself a long time ago )
question is, does it work now as you asked/wanted back then? 
9:37 p.m.
On Sat, Oct 8, 2011 at 5:16 PM, Paul Coccoli wrote:
Unfortunately it still does it. Turns me off every time I try doing
anything there. Given the need to write SMF files along with audio to
separate files, the Ardour approach would be preferable. Just my 2c.
Alexandre Prokoudine
http://libregraphicsworld.org
To detach a
clip from its siblings by giving it a new name makes perfect
sense to me still.... it would be nice to have some automatism that simply
iterates the filename. Some people feel a disturbance in the force, if they
have to switch from editing notes in a pianoroll to typing filenames ;-)
Yes yes yes. This is the worst "feature" of QTractor. I don't give a
$%^& what the filename of an individual clip is, and I don't want to
be interrupted to think about where on disk the file should be stored.
Stash it in a per-session directory, or a "clip library" or whatever.
Don't make me think about that mess I call my home directory.
DISCLAIMER: I haven't used qtractor in a while; I assume it still
works this way. If not, someone tell me to shut up.
9:40 p.m.
I would say either include them into qtractor project files or else just
save them with some nominal names, silently.
I did get used to just write some jibberish there and press Save when I need
to do things fast, but all in all I do not
see much use in naming various midi files. It is easier for me to rename
them later if I need to.
Cheers!
Louigi.
6 Oct
6 Oct
4:25 p.m.
On Thu, 06 Oct 2011 14:41:28 +0400, Artem Vakhitov <temcat(a)mail.ru>
wrote:
On 06.10.2011 14:11, Rui Nuno Capela wrote:
Do linked clips stand out visually somehow? I think it would make
sense to make the link easily discoverable - say with color, labeling
etc.
Also, in addition to (or instead of) the Unlink/Detach option it
would be nice if the program just asked the user who attempts to
change a linked clip (or save a linked clip that has been changed)
whether he/she wants to change all the related clips or just this
one.
i'd prefer to think "the mighty user" always know what he/her's doing
;)
too much nagging questions were once the ban in qtractor. after some
power-user requests, it all got leveled down to a bare minimum, and to
good measure, if i may say :)
you might have a better idea now. or you could elaborate one even
further. let's know about it :)
let me not wait in vain
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Nice nice
and useful too but then again.... what if I copy/paste a
drum-clip and want to add a crash-hit to it whithout having that
crash
on every clip the copy has derived from? Is there some option such
as
"right-klick/make new individual clip from copy"?
you'll have to pick the clip in question, the one you wish to unlink
or
detach, and from the midi editor window (aka. piano-roll) you should
save it with a brand new midi filename (ie. File/Save As...)
maybe this could go as an "one-click" procedure, like you suggest,
as a
new clip context-menu entry: "Unlink" or "Detach" or whatever:).
noted.
8 Oct
8 Oct
10:37 p.m.
On 06.10.2011 18:25, Rui Nuno Capela wrote:
Sure, but why not help him or her a bit - that's the reason we have
computers. It's a tad hard to read and compare file names on all the
clips out there, but if you have for example a chain icon and the same
color for all linked clips, it gets much easier to spot each linked set.
Discoverability rules ;)
On Thu, 06 Oct 2011 14:41:28 +0400, Artem Vakhitov
<temcat(a)mail.ru> wrote:
<skip>
Do linked
clips stand out visually somehow? I think it would make
sense to make the link easily discoverable - say with color, labeling
etc.
Also, in addition to (or instead of) the Unlink/Detach option it
would be nice if the program just asked the user who attempts to
change a linked clip (or save a linked clip that has been changed)
whether he/she wants to change all the related clips or just this one.
i'd prefer to think "the mighty user" always know what he/her's doing
;) too much nagging questions were once the ban in
qtractor. after some
power-user requests, it all got leveled down to a bare minimum, and to
good measure, if i may say :)
I don't think that this will be asked too often. Besides, you can add an
"Always do this" checkbox together with options in the clip context menu
to explicitly request one of the two actions (again, possibly offering a
"Do it always from now on" option in cases where the user has chosen an
action that is not the current default).
Artem
4797
days inactive
4800
days old
linux-audio-user@lists.linuxaudio.org
17 comments
9 participants
participants (9)
-
Alexandre Prokoudine -
Artem Vakhitov -
Hartmut Noack -
Jeremy Jongepier -
Louigi Verona -
Paul Coccoli -
R. Mattes -
Renato -
Rui Nuno Capela