Add new comment

Thanks as ever for the quick reply. Sorry for the long post yet again, but...

1) AUDIO EXPORT/MULTIPLE BUSES
I'm not that familiar with the technicalities of file formats, but after a bit of research, I think I understand :-) I generally export to FLAC for archiving and convert to ogg for distribution, but it seems FLAC doesn't support floating point. So to confirm - if I were to switch to, say 32 bit float WAV and export a file which is clipped, do you mean that I can just lower the level of the sample to 0dB or below and this will preserve all the data? I've just done some tests in Audacity with clipped FLAC and 32 bit float WAV files and they do indeed behave very differently, the WAV file seemingly working OK.

Do you have any thoughts on the second part of the post ("Doing it this way... rather than duplicating everything in each bus")? At the moment, with multiple buses I'm having to connect each one to JAMin etc separately. Is this the intended way? Previously, when using Ardour, I had all the buses etc returning to the Master Out and just added one Insert to JAMin, which was very easy. It seems such an approach might not be possible in Qtractor?

2) PIANO ROLL - QUICK-SAVE
> you might find it wrong, redundant or even confusing, but yay, that's the way it works :)

Yes, I have been utterly confused by this :-) If by pressing Ctrl-S in the MIDI window I am actually saving the work I'm doing in that particular file, then that's fine (as it's the only file I'll be working on at that time). It's still confusing though, as pressing Ctrl-S with the MIDI window having focus doesn't remove the [modified] text from the window. So...

- Should [modified] disappear from the MIDI window upon pressing Ctrl-S (with the MIDI window having focus)?
- If I save "the whole show" in the main editor, open a MIDI window, make a change, then press Ctrl-S (with the MIDI window having focus), should [modified] disappear both from the MIDI window and the main window? Although I'm not saving "the whole show" here, I'm saving the only thing which is having an influence on it

Basically, I think the design as you've explained it is fine, but at the moment, there's no visual feedback as to whether the save has worked or not, which is confusing (at least to me).

3) TEMPO MAP/MARKERS NOT RESTORING
> what exactly is not restoring and when?

It's difficult to pin down as I often won't notice that something's gone wrong until much later, but I can give you my recollections/impressions (again, apologies for the vagueness). As I mentioned, if you could give me any hints on the kind of things I can try in order to "break" this, I'd appreciate it.

- I've seen both tempo and time signatures not restore correctly
- Sometimes entries will be present, but incorrect (e.g. tempo figure wrong); sometimes they'll be missing altogether. When things go wrong, it's often the way that not all entries are wrong - some can remain correct
- What seems to happen is that Qtractor can "remember" a previous setting for an entry, then incorrectly revert to this setting after other changes are made later. As time goes on and more changes are made, the problem worsens as Qtractor becomes "more confused"
- I suspect, though really am unsure, that using the "Update" button can throw things off. I've noticed that after making several changes and attempting to "Update", the button will sometimes be greyed out, when it should be active and ready, indicating that at least something isn't right here. Again, it's as if the tempo map is becoming "confused"
- I also suspect (though again am unsure) that making various changes, then returning to make changes in the middle of a list of ones you've already made, can throw things off
- In terms of entries going "missing" - as an example, a piece I was working on had about 6-7 tempo and time signature changes. After working on the file for a while, making saves/re-opening the file, I eventually discovered that only three of these changes remained in the Tempo Map/Markers box. I was unable to work out exactly when things had gone wrong
- The problem seems to happen mostly on re-loading a save, but I think there's a decent chance it's also happening while working on the file in the standard way (see next point)
- I'm reasonably sure I've seen the problem happen in realtime. When playing back MIDI files and following them in the MIDI editor, upon passing over a tempo/time sig mark (not sure which), I'm sure I've seen the window "jump" as the change is re-read (incorrectly?)
- I've tried making changes solely through View -> Tempo Map/Markers and solely by clicking the bar marker area above the MIDI tracks, but neither seems to be stable. Is there any difference in these methods?

> is it easily reproducible or just happens sometimes and hard to remember what and when?

As above, it's difficult to pin down. I've been trying to reproduce in a small test file to be able to send you a .qtz, but haven't been able to get anything so far. I also don't have any examples from previous projects, as due to their having become such a mess, I ended up removing as many of the changes as possible.

> tempo/time-sig changes must only occur at bar measure positions

Yes, I understand. This is no problem.

> use the timeshift MIDI tool to emulate accelerando/retardandos on individual MIDI clips

I did look into this feature previously but it wasn't quite what I needed, as using it throws off the bar lengths (I understand that this is what's it's supposed to be doing). Given that I'll likely still need to adjust the time signatures in order to put in things like brief pauses, and given that tempo changes can only occur in defined places, I think that using both features will make things a bit of a mess. I think I could live without tempo ramping if we could isolate and fix the non-restoring Tempo Map issue.

4) TEMPO DIALOGUE BOX UNNECESSARY PROMPT
Just found another small bug during today's tests.

- Right click MIDI clip -> Clip -> Tempo Adjust
- Cancel without making any changes
- "Some settings have been changed." prompt will appear unnecessarily
- n.b. the default settings in the dialogue box will be 90.0 4/4, regardless of the clip's properties. Even when proceeding as above on a clip of 90.0 4/4 (i.e. the same as the default settings), the prompt will still appear unnecessarily

It's very similar to this previous bug:

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