You are here

Mixer volume not honored upon initial loading of project

I've been working around what feels like a bug for some time now and finally decided I should stop and report it.

So for a given track, I've got the mixer volume pulled down to 50 %. I save my work, life is good.

I come back later, open the file and upon playing the track, I notice volume is at 100 % (mixer track still shows the intended 50%).

My work-around has been to "nudge" each of these non-100% tracks in order to get things sounding the way they should. Of course, this is horrible.

I should also point out that from a MIDI perspective, all my tracks are driving carla-hosted plugins via dedicated MIDI busses. I've taken care to configure each plugin's MIDI abilities as shown in the attached image. As a result, every day operations are always reliable aside from this one issue involving the initial "seeding" of each track's volume.

20 years ago, I'd have just set a CC=7 value for each track at 00:00:00 but that feels shameful now. Am I nuts to think Qtractor should be sending an initial MIDI controller event when the track begins playing based off the state of the track's volume in the mixer? If not, how is this supposed to work?

Thanks in advance for any insight

AttachmentSize
Image icon Screenshot_2021-07-08_00-07-08.png71.48 KB
Forums: 

This seems like an obvious race condition here since both Carla and Qtractor are persisting state.

Opening Qtractor first could never result in everything being routed since the instruments (along with their midi and audio ports) don't yet exist. They won't exist until the appropriate .carxp session file is loaded in Carla. As such, loading the project in Qtractor only results in the internal audio routing being established.

On the other side of the equation, loading the Carla session first wouldn't work either since all the ports maintained by Qtractor don't exist yet.

So basically, it's a chicken/egg scenario.

Can this "send initial controllers" thing be broken out in some way as to allow the end user to drive it as needed? Anything would suffice, a button, a pull down menu option, anything.

All the best

rncbc's picture

let me tellya a story about this:

carla is and has been a do-it-all-as-a-plugin and/or anything-must-be-a-plugin (or seen like such)--that's its thing.
qtractor does not, and won't follow that model, may I say... ever.

you seem to run carla as a standalone, which is not it's designated use case for crying out loud :) when in that sort of function, does it handle ALSA-MIDI connections smoothly or does it resort to some bridge that, yes, may be the culprit for the so called "race-condition" you point out?
I think it is not fair to call the said "bug" on qtractor, and that's the problem here, I believe.
It's kind of a, yes, a conundrum :)

I'd suggest, in your situation, to do the following: do not rely on the MIDI track strips volume/panning sliders whatsoever. keep them on default position all the time; you may take automation but well, given that carla is becoming such a totalitarian and bloated beast, you, are, on, your, own ;)

eh eh, sorry for the sarcasm
cheers

I have no problem with sarcasm but this is a seriously lame response on so many levels. Not sure what you're so angry about but there's no reason to take it out on me or the software. All I did was point out an extremely valid use case (one I know you are quite familiar with) and show where an oversight exists. It's this kind of "my way or the highway" attitude that's kept Qtractor where it's at in my opinion and this is why adaption isn't improving. Rather than telling people to go !@%! themselves, how about a little gratitude for those of us who use it and take the time to point out where obvious improvements can be made? Especially something like this where nobody is asking for anything new to be created. Obviously the code already exists to "initialize" a project... the ask was to simply make it accessible. This also has nothing to do with Carla so I'm not sure what's triggering you there.... not sure I want to know actually. Whatever, it's your choice. You like this thing the way it is, fine by me. I won't bother letting you know where it can be improved going forward.

rncbc's picture

oops. i didn't even try to make a stand; I just made a suggestion for you not relying on those controls (MIDI track's volume and panning) for what you seem to be doing; that's all; because the way qtractor works in that regard doesn't seem to work with carla standalone use case; it does work on so many other soft- and -hard-synths, internal and external, as far that I remember, since it was conceived more than a decade ago.

please don't take it personal. I'm actually willing to try and experiment with a possible new option, like enforcing the send of all MIDI track/channel controllers on start of playback (as I posted earlier); would you care to try that option in first hand, please?

again, my sincere apologies if I sounded harsh or dismissal of your good will, somehow.
cheers

I do appreciate this and would certainly be willing to try anything that would help overcome the issue. I'm obviously a fan of this software and have always posted to this forum with the intentions of seeing it become more and more useful. I do realize this software has been in development for awhile as work-flows have evolved and changed. Hell, 20 years ago, I started using a MIDI sequencer to control everything externally (insert SYSEX message flashbacks here). Now, everything (and I mean everything!) is software. Believe me, I totally get it. As I re-entered the world of DAW all these years later on GNU/Linux, I went through all the obvious candidates such as Ardour, MuSE, and a few others. I found Qtractor to be the most usable and most functional Free Software solution by far and never looked back. You may remember Carl, who showed us his awesome work flow where all the instruments were basically outsourced to Carla via MIDI busses and AUX returns... That was a huge milestone in terms of getting a solid work flow in place; one that was both very flexible and very stable. Sure, there are some downsides in terms of additional tedious steps one has to go through when it comes to the frequent need to create and route new endpoints) but it's well worth it. At the end of the day, it's about being able to sit down and be creative with a set of tools we don't have to fight with. Again, I appreciate your work and have been trying to help in my own way by simply sharing a particular end-user perspective. It's all good.

rncbc's picture

fyi. qtractor >= 0.9.23.8 already has the option available for you to try...

although it's not accessible (yet maybe) from the GUI. you can turn it on by editing the config file (~/.config/rncbc.org/Qtractor.conf) and change or add the following entry line under the [Options] section (please do this while qtractor is not running):

Midi\ResetAllControllers=true

good luck :)
thanks

PS. qtractor >= 0.9.23.9 already has it accessible from the GUI: menu View > Options... > MIDI > Playback > Reset all controllers on playback start. cheers

Boom! This is working as expected (verified via Sherlock MIDI Inspector). Thank you very much. This is a great addition as it lends itself to a repeatable environment that matches the expectation of the user. The fact I no longer have to "nudge" things before getting back to work on a loaded session is a huge time saver but more importantly, it removes a silly ritual from my work flow. Thank you for this!

rncbc's picture

great! thanks a lot!
now,... please keep harnessing it... the code you just tested has been refactored a bit :) please try again with qtractor >= 0.9.23.11, with and without that option set; probably it now works either way upon initial session/project loading... (remember that new option applies to playback start only)
you tell me ;)
cheers && thanks in advance

Sweet. I'll git pull and spend some time with it later tonight. Thanks again.

Seems like all is working as expected. Thanks again. Great feature!

Pages

Add new comment