You are here

A few random points (UI, behaviour)

Hi Rui,

I've collected some things which have cropped up over the last few months or so and on which I'd like your opinion. I'll list them below - please let me know your thoughts whenever you have time. FYI, I'm using r4035.

Thanks very much.

When there are many plug-ins on a track, it'd be useful to be able to use the scroll wheel to move up/down through them as the scroll bar is rather small. Currently, this doesn't appear to work, whether you have the track selected or not. (I think it may have worked a while ago, but may be imagining this :-))

It only seems possible to mute/un-mute/solo/un-solo one track at a time (unless I'm missing something?), as you can't Shift/Ctrl-click multiple tracks in either the Mixer or the main view. I frequently have to perform these operations on multiple tracks and clicking on each one becomes rather tedious on a reasonable-sized project. Would it be possible to allow these operations on multiple tracks simultaneously?

As mentioned in FEATURE REQUEST in this ticket, would it be possible to have Qtractor display relevant textual information, rather than just numbers? It'd be very useful to see things like "Stereo", "Ping-pong" etc, rather than just "0", "1" etc.

These feature requests have been up for a while and I'm quite interested in them myself:

Do you have any plans for anything like these, even at the bottom of the ToDo list?

The combo box in the bottom right (Session files/Template files/Archive files) no longer includes information on the extension (qtr/qtt/qtz), so new users may not know how to name file extensions correctly. Is it worth putting this information back in, or has it been removed for a particular reason?

rncbc's picture

hi, quick replies...

will see if this gets handled asap. from the top of my head there might be a clash with the direct-access parameter sliders, but not sure yet. [UPDATE:] svn trunk r4043 aka. qtractor might have news for you ;)

in general no. in particular there's something else :) however, there are no plans to have multi-track/group selection. sorry. but while on the specific subject of mute/soloing multiple tracks at once, you have this kind of "boolean" approach behavior that applies when clicking over the [M]ute/[S]olo buttons and whether you make it so with Shift or Ctrl keyboard modifiers--you'll have to try yourself:)--hint: might be handy to know how it behaves: think of it as an old ester-egg hidden in there, in case you missed all this time ;)

you're not the first and certainly not last. i've been procrastinating this topic for longer than it's barely excusable. meanwhile, no. it won't happen before this next dot release. sorry. :S

and what do you really want to do with that information anyhow? any broken recording is a broken recording. nevertheless. if you hear it as broken, it is broken. it really doesn't matter it has been marked as "clipped" or with a "xrun" (the later may even be inaudible, but yeah a get your point:)).

for instance. actual "clipping" situations are mostly dependable on which file and sample format you're recording to. on a "float" format it really doesn't mean your recording is broken. otoh. an "integer" one surely gets damaged if audio signal swing gets over 0dbfs.

well, this is something that most likely pertains to your native's DE file requester dialogs implementation. (DE stands for your desktop environment in charge, eg. kde, gnome, xfce, etc.).

try turning View/Options.../Display/Dialogs/Use native dialogs off. then you'll get Qt's own file dialogs and there you should have slightly different sort of display. but ymmv ;)


Thanks very much for the replies. Here we go...

Tested in r4046 and it's fixed. Thanks :-)

> you have this kind of "boolean" approach behavior
Thanks - wasn't aware of that. I've had a play and it looks like this does basically what I need. The behaviour seems to be:

Shift-click Mute/Solo: Enable/disable state on all tracks. Takes its cue from the current state of the button actually clicked (if currently disabled = enable all tracks; if currently enabled = disable all tracks)
Ctrl-click Mute/Solo: Enable/disable state on this track only. e.g. Ctrl-solo-ing a track with other tracks already solo-ed, will un-solo those other tracks, leaving just the target track solo-ed
Shift-click Record; Ctrl-click Record: No special function

Is this the desired behaviour? Please confirm whether it's working as intended and, if so, I'll add this information to the wiki, as it doesn't appear to be there at the moment... unless, that is, you want to keep it as an Easter Egg :-)

OK. It's not a huge issue, but will definitely make things "nicer" if/when you do eventually find the time.

> and what do you really want to do with that information anyhow?

Here are some examples:

As bouncing from MIDI to audio is real-time it can take a while on a long piece, so I'd like to be able to leave Qtractor running and come back when it's finished. If I come back and find an x-run reference in the Messages window, I know there was/could have been a problem, but won't know where this occurred (unless I methodically count backwards to the time code quoted or something). I don't get x-runs very frequently, but they can occur. Having a visual representation tells you exactly where the problem occurred so you can check and, if necessary, re-bounce just that area straight away. This saves a lot of time on a long piece. And even if you are present during bouncing, you may not be watching at the exact time the x-run occurs, so the visual representation is useful in any case.

Much like the x-run situation, after making an audio recording and returning to the PC to check it (I record away from the PC to minimise noise), it'd be nice to see at a glance if anywhere had clipped, so I could check/re-record that section straight away. As you say, you should trust your ears and, of course, I'll be listening to the recording in its entirety at some point, but if the DAW can alert you to possible problems before you start more detailed listening, it can save a lot of time.

In terms of the actual representation, anything would be fine, but I was originally thinking of something like you see in Audacity.

In terms of formats, I usually record in FLAC, which (as I understand it) would produce clipping. The reason I use FLAC is, because it's lossless, I can then convert freely to other formats and it takes up less disk space than WAV. If you think there's a better format to record your "master" audio in (e.g. use Float WAV and take the disk space hit, to guard against clipping), I'd be very interested in any advice.

Neither of the above is a "must have", but I think they'd be very useful and would improve people's workflow (certainly mine, anyway).

Aha, yes that "fixed" it (I'm using xfce, by the way). Looks like it's not a Qtractor issue then, but new users may still get caught out (this window was where I first learnt about the different file formats, ages ago). I suppose they'll just have to read the documentation...

rncbc's picture

Is this the desired behaviour?
yes, you got it right :)

by all means, you're more than welcome to document the easter-egg behavior (no so anymore:)) on the wiki.

thanks && cheers

OK, have updated the wiki. Unfortunately though, after testing/eating the Easter Egg a bit more, it seems it isn't going to be as useful as I first thought: I can use it in some situations, but I often need to mute/solo just all audio tracks or just all MIDI tracks and, without a way to distinguish between the two/Shift-click multiple tracks/group tracks, this isn't possible. Looks like I'll have to continue doing things the long way :-(

And one more problem has cropped up this weekend, related to audio recording. I'll list what's happening below. Please let me know if you need more info, or want a ticket/qtz uploaded (have recreated on a clean file, for what it's worth):

(times quoted are just examples; actual times seem irrelevant)

- Connect mic to record audio directly into Qtractor (am using a Samson C01U USB mic)
- Start recording at 0 seconds; audio clip will be drawn on-screen as the transport moves (correct behaviour)
- Stop transport at 10 secs, using space bar/Play icon/Stop icon. Audio clip will sometimes "shrink" back - for example, though it was being drawn up to 10 seconds during actual recording, only the portion from 0 to, say, 5 seconds will now be seen

- Upon stopping the transport at the 10 second mark, it will remain there (correct behaviour)
- Start of the clip will always be correct - it's only ever the end of it which is affected
- Audio file actually records OK, but the clip isn't drawn correctly. You can drag the right edge of the clip to reveal the missing audio. You can also drag the recorded file from the Files window to the same position in an adjacent track and will see that it's correct - it will match the start of the original recording (0 secs) and the end (10 secs)
- Repro rate was about 70% on a project with a few tracks. Now, on a clean file, it's less than 5%
- I haven't seen this problem when bouncing audio tracks from MIDI (which was previously my main use for audio tracks); have only encountered it recently with direct recording

And, as per the above, if you have any advice on recording/clipping avoidance (stick to WAV, or whatever), please let me know.

rncbc's picture

maybe fixed on today's svn trunk r4053 aka. qtractor

test && tell

rncbc's picture

to be on the safe(st) side, i'd rather stick with WAV 32-bit float.

in most if not all cases when recording/writing into "integer" sample file formats, the encoded pcm audio signal often wraps or bounces over the 0dbfs soft-limit, introducing serious, unrecoverable and damaging distortion to the signal--not just the kind of easily flat-top clipping as a regular D/A device might do.

anyway, using a limiter is also an option.


Thanks for looking into the clip ending. I tested on the latest svn version using the file I had problems with (70% repro rate) and haven't seen the issue once, despite many attempts, so it looks fixed. If it does crop up again, I'll let you know.

Thanks also for the clipping info - I'll try a few options and see what works best for me. I still think an x-run marker would be very useful for the reasons listed above, but it seems you're not keen on this. Thanks for the reply, anyway.

I've just been adding some info to the wiki and realised I need to check something with you just in case. As mentioned here ("Be aware that session files..."), if the the user saves multiple "snapshots" of a session and changes the content of a MIDI clip in one of them, this change will be reflected in all snapshots. Is this the desired behaviour? It seems logical enough, but people who aren't familiar with the way Qtractor saves files may get caught out - they may think they can edit freely across multiple snapshots, when in fact, this isn't the case.

Please let me know if this is OK. (If it is working as intended and you'd prefer a different name to "snapshots" to avoid confusion, I can change it).

rncbc's picture

if the the user saves multiple "snapshots" of a session and changes the content of a MIDI clip in one of them, this change will be reflected in all snapshots. Is this the desired behaviour?

yes, it's the expected behavior alright: when taking snapshots in the xml/regular/default session file formats (*.qtr, *.qts) all audio/MIDI files are one and the same as they're external references or paths to the file-system.

however, if the snapshots are saved as a zip/archive session file format (*.qtz) then each one will bundle its own version of the audio/MIDI files, as each e get a compressed copy in each zip-archive snapshot.


Thanks for the confirmation. By the way, is there any difference between *.qtr and *.qts? I've had a look at both but couldn't see any obvious differences.


Add new comment