danboid's qtractor wishlist boils over

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

danboid's qtractor wishlist boils over

Post by danboid »

Those paying attention to these forums will prob be aware that qtractor is my fave Linux music app these days, however its still not quite at the stage for me to be totally happy with it yet. Everything that I think it is lacking I have reported in detail as feature requests on qtractors sf.net page some time ago and now the wait for these features to be implemented has got too much for me so I want to try do something to get them implemented quicker.

I want to do an album of (my own brand of) electronica and if I can't get these features added to qtr soon then I'm sad to say I'll be creating it with REAPER on a Hackintosh setup. Yes, I know REAPER runs well under wine but in my view running REAPER on a Hackintosh is more native (hence will perform better) and less likely to be flawed than running under wine, if your hardware is well supported by OSX86 (or you're running on a real Mac), of course. Using REAPER under Windows is out of the question as I only use Win when I am paid to. As you can guess, I really don't want to use REAPER although I do like it and I know it can do what I want it to.

I do know the very basics of C and C++ but I don't know it well enough to go adding significant new features to an app as complex as qtr so I'm hoping I can bargain with Rui and/or any other good coders out there who'd also like to see qtractor improve.

If Rui adds the ability to quickly add fave plugins to tracks ( http://sourceforge.net/p/qtractor/tickets/67/ ) I will pimp out the qtr wiki with everything I know about the app (and I've asked Rui A LOT of questions about it) and make other improvements and additions as I see fit. Many of you will be aware of my documentation and writing skills from the KX Studio ( http://wiki.linuxaudio.org/wiki/kxstudio_manual ) and JACKLab manuals, to name two relevant examples.

http://sourceforge.net/p/qtractor/tickets/7/

http://sourceforge.net/p/qtractor/tickets/8/

I posted these as two separate tickets but in my mind it's one and the same as they're both required to fix the amount of unnecessary clicking required to mix down MIDI plugin tracks. Should Rui implement these two I'll create a feature length qtractor tutorial video in return, better than what I did previously for A3.

https://archive.org/details/Introductio ... r_3.0_MIDI

Finally, I really badly want the ability to do tempo ramps within qtractor. qtr already has a timeshift tool which can simulate gradual tempo changes but its not what I'm after. I want the ability to be able to specify bpm's at specific points within the session and do gradual tempo gradients between the two. I do not require that it alters any audio tracks. I am willing to pay Rui or anyone else who can implement this £100 for their trouble. If anyone else really misses this feature then hopefully they'll be willing to contribute some funding towards seeing this feature implemented too?

Thanks Rui and anyone else interested!
tnovelli
Established Member
Posts: 277
Joined: Wed Apr 20, 2011 4:52 pm

Re: danboid's qtractor wishlist boils over

Post by tnovelli »

Yep, I like qtractor... I don't *love* it but at least it's reliable. My thoughts...

1. Fave plugins would be pretty straightforward to add... it's just GUI stuff. However...

2. Dedicated busses for each track? Just to play devil's advocate, I wonder if qtractor should do like the Non-tools: always create JACK ports for each track, and use an external mixer (qmixer?). That would be more in the modular spirit of qtractor. And why even host plugins in qtractor when you can host them in a mixer or in Carla?

3. Tempo ramping (ie. accelerando) would be nice. In theory we could use the existing automation system to control it, and interpolate the tempo at each jack period. It's probably an intertwined can of worms...

Do you know of any other JACK DAWs/sequencers/trackers that do tempo ramping?
tatch
Established Member
Posts: 662
Joined: Fri Nov 16, 2012 3:18 pm

Re: danboid's qtractor wishlist boils over

Post by tatch »

tnovelli wrote: 2. Dedicated busses for each track? Just to play devil's advocate, I wonder if qtractor should do like the Non-tools: always create JACK ports for each track, and use an external mixer (qmixer?). That would be more in the modular spirit of qtractor. And why even host plugins in qtractor when you can host them in a mixer or in Carla?
qtractor doesn't actually seem that modular to me. and non-mixer/carla are still lacking as plugin hosts because carla forces you to make an annoying amount of JACK connections and doesn't yet do automation very well, and non-mixer only supports ladspa and its automation capabilities only work with non-timeline.
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by danboid »

tnovelli wrote:
2. Dedicated busses for each track? Just to play devil's advocate, I wonder if qtractor should do like the Non-tools: always create JACK ports for each track, and use an external mixer (qmixer?). That would be more in the modular spirit of qtractor. And why even host plugins in qtractor when you can host them in a mixer or in Carla?
Yep, I'm advocating for the optional, auto-creation of dedicated busses at the time of track creation.

I'm very happy that qtractor is NOT fully modular like non-tools. Anyone who wants or needs that degree of modularity can use non but I'm grateful that I don't need to use a session manager alongside qtractor to create and re-load/share tracks. I think calling qtractor bloated (not that you did, exactly) or even slightly flabby is a stretch by anyones standards seeing as its all-inclusive (dynamically linked but uncompressed) binary is barely over 1MB.
tnovelli wrote:
3. Tempo ramping (ie. accelerando) would be nice. In theory we could use the existing automation system to control it, and interpolate the tempo at each jack period. It's probably an intertwined can of worms...

Do you know of any other JACK DAWs/sequencers/trackers that do tempo ramping?
Using the existing qtr automation system to control tempo sounds good to me.

Rosegarden, MusE and the late OpenOctave support tempo ramping. I've longed disliked RG's GUI (plus its support for audio is very weak), OO is dead and MusE's support for tempo ramping (via its graphical mastertrack window) is lacking because it doesn't have a line drawing tool so using it is awkward.

Rui is aware of this thread so lets see what he has to say..
User avatar
rncbc
Established Member
Posts: 1060
Joined: Mon Apr 19, 2010 12:20 pm
Has thanked: 45 times
Been thanked: 256 times
Contact:

Re: danboid's qtractor wishlist boils over

Post by rncbc »

hi all

@danboid, sorry for the delay, i think you already know about my proverbial slack of time and though i still think i've already answered most of your questions earlier back then, either in private or in the comments section of same or otherwise related tickets...
danboid wrote:[...] adds the ability to quickly add fave plugins to tracks ( http://sourceforge.net/p/qtractor/tickets/67/ ) I will pimp out the qtr wiki with everything I know about the app (and I've asked Rui A LOT of questions about it) and make other improvements and additions as I see fit. Many of you will be aware of my documentation and writing skills from the KX Studio ( http://wiki.linuxaudio.org/wiki/kxstudio_manual ) and JACKLab manuals, to name two relevant examples.
that is a good deal indeed although it sounds like bartering blackmail o.O) otoh. the feature in question is one kind of trivial as GUI coding is concerned... anyone? :)

personally I feel comfortable, while being enough for my own needs, the search box that has been featured on the plugin selection dialog--it preserves search history so it might well be of help; yes, it's not a full-blown favorite plugins app, but it's better than nothing ;)
danboid wrote:http://sourceforge.net/p/qtractor/tickets/7/
http://sourceforge.net/p/qtractor/tickets/8/

I posted these as two separate tickets but in my mind it's one and the same as they're both required to fix the amount of unnecessary clicking required to mix down MIDI plugin tracks. Should Rui implement these two I'll create a feature length qtractor tutorial video in return, better than what I did previously for A3.

https://archive.org/details/Introductio ... r_3.0_MIDI
well, i've told you before iirc. these are those kind of setup specific workflow helpers which i don't buy, at least so cheaply...

what's actually the trouble of making all those clicks, one by one alright, adding buses, tracks, plugins and connections layout, then save as a template *once* (.qtt) and mark it as the default new session model? that way, every time you start a new session you get your studio setup layout from scratch, every time, no more too-many-clicks boredom :)
danboid wrote:Finally, I really badly want the ability to do tempo ramps within qtractor. qtr already has a timeshift tool which can simulate gradual tempo changes but its not what I'm after. I want the ability to be able to specify bpm's at specific points within the session and do gradual tempo gradients between the two. I do not require that it alters any audio tracks. I am willing to pay Rui or anyone else who can implement this £100 for their trouble. If anyone else really misses this feature then hopefully they'll be willing to contribute some funding towards seeing this feature implemented too?
yes, we've been arguing about this tempo-ramps mantra way too long. again...

tbh. i don't pay much importance to this feature, and quite frankly i won't try to implement it in any reasonable time, no matter how greater the incentive... ;)

so sorry i just don't like it, in whatever way you may paint it pretty. you might well know that, in my age, i just don't start things that i don't like, sorry. imo. it's a MIDI-only feature, a pain to get right on both real-time and screen display, not to tell what way you'd prefer it to be operated on the GUI side of things--easy said than done, you know the drill :p

however, i won't stop you to ask whether anyone may step in to the call. i'm just not interested in doing it alone

no hard feelings, right? ;)

hyu.
cheers

ps. but it's not all bad news here: in svn trunk (v0.5.11.15+) there's this one mysterious entry in the change-log:
- When adding new tracks, try preserving the last selected bus names, while not the default Master ones (after a suggestion from danboid aka. Daniel MacDonald, thanks).
pps. danboid is now a member of the editors board of the starting qtractor wiki, just in case the fav-plugins trade gets real ;)
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by danboid »

Hi Rui!

No hard feelings - I just wanted to give those issues one more shot on the off-chance you may reconsider any of them. I've got to see this as good motivation to sit down and learn Qt and C++ properly I suppose, which would be great skills to have.

The latest svn addition sounds like it should help streamline new track creation a tad if its not quite as extensively automating as I'd prefer. Thanks for that!

I'm well aware of making templates for qtr but if my suggestions got implemented, creating those templates would be faster and easier - same goes when you deviate from your template and need to add new tracks.

If I'm lucky, someone will see this thread and get inspired.

PS Will look into what I can add or improve on the wiki soon!
tnovelli
Established Member
Posts: 277
Joined: Wed Apr 20, 2011 4:52 pm

Re: danboid's qtractor wishlist boils over

Post by tnovelli »

I've been thinking about tempo ramping a little more. I noticed that the JACK Transport API does not support variable speed... so even if other sequencers/DAWs/etc supported tempo ramping, keeping them in sync would be dicey. You'd have to 'fake it' like I currently do:

1. Record/enter the notes in free time (ignoring beats)
2. Change the tempo before and after, such that the tempo ramp begins and ends on the beat.

Automating this would certainly be handy - you could change tempos without having to readjust or rerecord the transition notes. Mainly a MIDI thing (maybe audio too with librubberband or something?) Not a priority for me but I'll put this on the wish list for my 'Tritium' sequencer... if it's not too much trouble in a clean-slate project, it might find its way into Qtractor eventually.
paulmerchant
Established Member
Posts: 42
Joined: Sat Oct 27, 2012 3:43 pm
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by paulmerchant »

klick is a fairly easy to use command line+script tool for Jack that can automate complex tempo changes for your projects, including tempo ramping. It would be much easier to add an instance of klick as the time master to your projects than to try to add klick's features to qtractor.

I tested tempo ramping and other complex time changes with klick not too long ago, using a number of different work flows and apps. Most everything stayed in sync (can't remember the problem child or two).

If you wanted to code something with your current skills instead of diving into qtractor, a GUI for klick might be a fun project. [edit: I mean a GUI that can create all the tempo maps, etc. A simple metronome GUI is already available.]
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by danboid »

klick sounds interesting so thanks for pointing that out Paul! I'll check it out soon.

Its quite funny actually if Klick does what your say it does as I'd come to reply to Mr Novelli and to say, yes, I knew of JACK transport's lack of tempo ramping but that I'd never felt any need to use JACK transport but now you've pointed out Klick's ability to ramp tempo I'm quite interesting in using JACK transport all of a sudden! :)
tnovelli
Established Member
Posts: 277
Joined: Wed Apr 20, 2011 4:52 pm

Re: danboid's qtractor wishlist boils over

Post by tnovelli »

Klick... ok, we're getting somewhere! Errr, wait... qtractor doesn't read klick's tempomap. There IS a klick2ardour script which overwrites an Ardour session's tempomap, which could easily be adapted to Qtractor (both session formats are XML)... and it even accounts for tempo ramping (the average_tempo function). And Qtractor doesn't follow klick's tempo reliably (Hydrogen does). Even if someone fixes that, it seems like an awkward workflow.

I guess Klick works fine with simple stuff like Hydrogen (see http://linuxmusicians.com/viewtopic.php?f=19&t=2290). But if you "just want to add a little ritardando" to a Qtractor work-in-progress, you're probably out of luck.

If anyone wants to try what I did... Paste the following into a file called tempomap and run "klick -PT -f tempomap". Then hit the play button in Qtractor or Hydrogen.

Code: Select all

3 120
1 120-180
3 180
1 180-100
4 100
tnovelli
Established Member
Posts: 277
Joined: Wed Apr 20, 2011 4:52 pm

Re: danboid's qtractor wishlist boils over

Post by tnovelli »

BTW, beat following would be much cooler than mere tempo ramping.

I assume fully automatic beat following is error-prone. I was thinking manual -- record an acoustic track without a metronome, then tap a key on the beat during playback to create a tempo map -- yes, with a tempo for every single beat. Ramping would be nice. Graphical tweaking (to line up a beat with a waveform) would also be nice.

Just a wild idea :)
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by danboid »

I didn't find time to test klick before today and unfortunately T is correct in stating that qtractors playback falls apart when klick tells it to try doing accelerando or ritardando. As I say in my bug report for this ( https://sourceforge.net/p/qtractor/tickets/76/ ), MIDI tracks seems to fall out of sync with one another in 'Full' transport mode and in slave mode the transport stops playback after playing the first event.

There is a gtk gui for klick but it appears totally useless for my purposes. The klick tempo map file format couldn't be simpler though so I think I'd be OK using klick from the terminal if qtractor gets fixed to handle varying tempos as a JACK transport slave.

Should this get fixed, the next test would be to see if its possible to record and playback audio within a qtractor / klick session that features tempo ramps without sync hell breaking loose?
paulmerchant
Established Member
Posts: 42
Joined: Sat Oct 27, 2012 3:43 pm
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by paulmerchant »

I remember there were problem apps and workflow issues with klick when I tested it. I should have documented what worked and what didn't. It sounds like qtractor's midi playback was one of the problem children with how klick does it's tempo ramps with jack. Maybe there's a work around converting the jack time to midi. I didn't mean to send you down a path that wouldn't work. :(
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by danboid »

Not a problem Paul - I'm glad you pointed this feature of klick out anyway. Your guess as to what is causng the issue sounds like a likely one seeing as qtractor doesn't support JACK MIDI. I hope it can be fixed without!

I've just added the following comment/correction to my bug report:

The MIDI tracks don't really fall out of sync with one another when klick is ramping the tempo and qtractor is in Full transport mode. A more accurate description of the problem is that not all notes get played when the tempo is changing.
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: danboid's qtractor wishlist boils over

Post by danboid »

Rui really has no plans to implement tempo ramping in qtractor, no matter what angle we take. Here's his response to my bug report:
what you're trying to do is not well supported by jack transport or qtractor by any chance.

tempo (bpm) changes are informational data that get set by a time master jack client, both klick in your case and qtractor when in full transport mode.

there can only be one jack transport master at any one time. having both klick and qtractor as time masters leads to undefined behavior due to unpredictable race conditions on which one sets the current jack transport tempo or bbt position first.

and when qtractor set as a slave can hardly catch up with tempo ramps, just because it doesn't do any at all: tempo changes are read as a whole and qtractor will just set it globally or to the nearest existing tempo map node/bar position.

you can always have interesting or funny rhythmic results though but hardly the ones you'd ever expect, deterministically speaking ;)
Is this a planned feature for Tritium TN?
Post Reply