Add new comment

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

MIXER - MOUSE SCROLL WHEEL
Tested in r4046 and it's fixed. Thanks :-)

MUTE/SOLO MULTIPLE TRACKS
> 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 :-)

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

X-RUN/CLIPPING INDICATORS
> and what do you really want to do with that information anyhow?

Here are some examples:

x-run
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.

Clipping
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).

SAVE SESSION WINDOW (FILE/SAVE AS)
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...