You are here

Home › Forums › Projects › qtractor

Bug: Unable to select a clip when dedicated MIDI control I/O is connected

10 February, 2024 - 20:28 — windowsrefund

How to reproduce:

  1. Enable the Dedicated MIDI control I/O feature in Options/MIDI.

  2. Create a duplex MID bus. For the purpose of this thread, we'll name it CCAuto.

  3. In Connections , connect Qtractor/CCAuto to Qtractor/Control on the MIDI tab.

  4. Navigate back to the track view, click on a MIDI clip (create if needed) in order to select it.

Normally the clip will turn blue indicating it has been selected. This will fail until the previously mentioned MIDI connection is removed.

Forums: 
qtractor
10 February, 2024 - 21:56 — rncbc
rncbc's picture

failed to reproduce, nothing weird happens here, clip gets selected and shows as usual.

anyone else?

11 February, 2024 - 04:02 — windowsrefund

Even as i was posting, I knew I should really report that (alegged) bug against a generic qtractor install absent of the .qss theme. I'll go through that tonight and if I can still duplicate, I'll include screenshots.

11 February, 2024 - 08:02 — windowsrefund

Ghosts in the MIDI

Yea, strangeness. I've been able to get it working but am seeing inconsistencies. It seemed I was reproducing the original problem when setting this up against an existing .qtr file so I created a new file with data first and then setup the control connection. That worked. OK, what's different about those files?

grep says the schema is different between the new (ControlTest.qtr) and old (Test.qtr)

> grep -B3 CCAuto ControlTest/ControlTest.qtr
     </midi-patch>
    </midi-map>
   </midi-bus>
   <midi-bus name="CCAuto" mode="duplex">
--
   <control-inputs>
    <connect index="0">
     <client>128:Qtractor</client>
     <port>3:CCAuto</port>

> grep -B3 CCAuto Test/Test.qtr
     </midi-patch>
    </midi-map>
   </midi-bus>
   <midi-bus name="CCAuto" mode="duplex">
--
    <input-connects>
     <connect index="0">
      <client>128:Qtractor</client>
      <port>1:CCAuto</port>
--
    <output-connects>
     <connect index="0">
      <client>128:Qtractor</client>
      <port>1:CCAuto</port>

I'm actually not even sure how I got it working in Test.qtr at this point but I can select clips now and I also got it working in another already existing file where the data ended up looking like what is shown in the first example.

I think we're good. Must have been a ghost in that Test.qtr file or something.

11 February, 2024 - 18:33 — windowsrefund

OK. I believe I have figured out the exact work flow which results in not being able to select a clip. These steps assume no part of the mentioned bus and related connections exist or are configured.

  1. Enable the Dedicated MIDI control I/O feature in Options/MIDI. (restart Qtractor if needed... I can't remember).
  2. Create a duplex MIDI bus. For the purpose of this thread, we'll name it CCAuto.
  3. Create a track assigned to use the CCAuto MIDI output.
  4. Create a clip on the new track (can be empty).
  5. In Connections , connect Qtractor/CCAuto to Qtractor/Control on the MIDI tab.

The previously created clip (or any clip for that matter) can not be selected by clicking on it.

FIX: The fix is simple; change the previously mentioned track's MIDI output back to master; save; then change it back to the CCAuto.

Any clip can now be selected.

11 February, 2024 - 19:12 — rncbc
rncbc's picture

gotcha!

and to fix it you just need to switch the MIDI output bus to "Master" and back to "CCAuto" immediately, no need to save and reload.

howver I don't have the slightest clue why it behaves like that and kinda reluctant to spend time in investigating this erm... glitch :/

is it so important or critical for you?

thanks

11 February, 2024 - 19:25 — windowsrefund

Thanks for confirming. I'm not sure how important it is as I continue to see disruption in various forms. In other words, if it was a one-time thing, I really wouldn't care. However, I'm also seeing where my assignment (made against the slider) is not persisting. In other words, my assigned cc=3 is showing up as cc=10 on the pan slider so I just got the crazy idea to disable the "Reset all controllers on playback start" option to see if I can identify a potential race condition my imagination allows me to entertain.

So yea, I haven't done a great job of scoping this yet but am still investigating.

11 February, 2024 - 19:42 — windowsrefund

Through trial and error, my assigned cc=3 is automating the pan slider on my bus.... awesome. Not sure how stable it will be (or repeatable) but here's something worth seeing...

Right clicking on that slider, I'd expect to see cc=3 (as that's what is assigned). However, I see this

hmmmm

BTW, I am now running with the "Reset all controllers on playback start" option disabled. I mentioned "trial and error" because I did have to reconnect the existing MIDI connection somewhere along the way. I'm just trying to figure out a reliable work flow as I'm convinced this is a killer feature I need to lean into heavily :D

File attachments: 
Image icon why10.png
11 February, 2024 - 20:13 — windowsrefund

I now know the following.

  • "Reset all controllers on playback start" MUST be disabled. It can be disabled during an active session (no need to restart Qtractor). Once disabled, the automation track needs to have its MIDI output toggled back to master and then the MIDI output used for automation once.
  • The automation track should be configured to transmit on a unique MIDI channel. This solves the conflict shown in the above screenshot and is most likely also needed to avoid other sensible race conditions.
  • The target of the automation data should be set to receive on the same MIDI channel as the automation track.

The feature now works reliably within the running session.

What about across sessions?

Opening the session again results in the issue originally discussed where clips can not be selected. The automation track's output "toggle fix" can be used once to produce a working session.

11 February, 2024 - 20:45 — rncbc
rncbc's picture

wait a minute!

in case you missed, long ago, the MIDI track volume and pan sliders have hard-wired permanent MIDI controllers of their own: CC#7 for channel volume and CC#10 for channel panning (as of the GM standard).

there's probably no use in assigning any other MIDI controller to these.

byee

11 February, 2024 - 21:14 — windowsrefund

Well sure, I'm quite aware of cc 7 and cc 10 but we've been talking about automating the buses this entire time .

12 February, 2024 - 08:24 — rncbc
rncbc's picture

however,

that's the reason why CC#10 it appearing in the screenshot above and not the custom cc#3: it is being captured by the dialog in real-time, due to so called "MIDI Learn" feature; as long you don't hit the "OK" or "Reset" buttons your previous assignment won't get dismissed.

and, what kind of automation are you trying to achieve on buses with all this? it seems to me, that you're about to get the trouble in having a nasty positive feedback loop and hosing the MIDI track in question (eg. MIDI track vol/pan -> CCauto out -> Control in -> MIDI track vol/pan)...

now, qtractor >= 0.9.39.12git.16452b is set to mitigate the effect but only applies to standard MIDI track volume and panning controllers and most probable cause for the OP (non-selectable clip issue).

hth.

13 February, 2024 - 06:05 — windowsrefund

Just took this for a spin and can confirm it overcomes the need to reset the sending track's MIDI output. Thank you.

12 February, 2024 - 15:13 — windowsrefund

Ah nice. I don't really understand the feedback issue but will take this for a test drive tonight. Thank you.

12 February, 2024 - 20:34 — rncbc
rncbc's picture

please, take special note that this is just a mitigation, it's NOT a definitive solution whatsoever. for sure.

you shouldn't make such MIDI control feedback loops to begin with--it's just one way to achieve the proverbial undefined behavior (iow. a race condition galore:) it's just luck that contemporary machines are increcibly fast nowadays; a few years back it could just freeze, crash, or worse. i'm not kidding, mind you.

you're here advised to avoid those scenarios, as much as you can; if you disregard this advice, then: caveat emptor!

cheers

13 February, 2024 - 04:10 — windowsrefund

I'm all ears and am just trying to understand. In a nutshell, are we saying we should avoid attempting to automate bus volumes and pans as mentioned in this earlier post?

My take-away from the approach is that we're essentially treating those endpoints as if they are external MIDI devices. As such, we're just feeding them control data; something I'm quite comfortable with. Not sure what I'm missing here but am certainly curious.

13 February, 2024 - 09:34 — rncbc
rncbc's picture

no, you should avoid automating bus volumes and pannings from MIDI track sliders through ta deadly control loop-back (which potentially leads to an infinite recursion situation).

remember the pitfall: MIDI track pan (cc#7) -> CCAuto out -> Control in -> MIDI track pan change (cc#7) -> CCAuto out -> Control in -> (repeated ad nauseam...)

although it's been mitigated as said, for stability it doesn't solve at all the cases when you ever touch the mixer sliders (volume or panning): they may well start flicker'n'flippin forever after (as an extra bonus to having non-selectable clips:)).

byee

13 February, 2024 - 11:13 — G3N-es

For the music I make, automation is dispensable.

However, for a future toy it seems very interesting.

I also didn't understand the "death loop."
By doing tests I think I understood it.

The problem is that the CC data always works on the Bus_Master, even if you have another Bus assigned to the track.

This should not be like that.
An independent bus should work as its own application without dependency and have its own sending and receiving of CC data.

In fact, I have tried to create the same proposed workflow, but instead of with a Bus_Auto, opening a new instance of qtractor and using it as Bus_Auto. It is not produced there because they are independent.

Well, in a single instance of Qtractor it should be the same. Each bus should work as an independent instance.
The data should not always be received by Master, but by the Bus that we have selected.
In addition, it should be possible to receive CC data from any Bus and not only from the Master.

I don't know if my diagnosis is correct, but I suspect it goes there.

13 February, 2024 - 11:30 — G3N-es

The solution you are looking for may be two Qtractor sessions open on two Qtractor instances at the same time.
In the automation session you can rename the Bus Master as "Automation" to avoid confusion and easily identify which instance is dedicated to automating and which is to be automated.

This would also simplify the organization of tracks. I would divide the work window into 2, Left (or Below) Automation, Right (or Above) Sound.
Hiding the time and other tools expendable in the automation instance would feel like an internal module created expressly to automate, even though it is not.

14 February, 2024 - 17:30 — G3N-es

Rectifications

I take back what I said. If it is possible to automate without causing the loop with a single instance.

The buses behave well on Qtractor and my assumptions were wrong.

(It is not the first time nor will it be the last that I think that Qtractor does not do something correctly, and I am wrong. Qtractor does it well, I just don't understand how it does it yet.)

I have returned to Mela's proposal to understand why the loop does not originate there.

It's simple, the automation must have an id lower than the control so that the loop does not occur.
(Related: Now I understand the strict order of AUX SEND)

What I don't understand now is because the PAN is easily automatable on an audio bus, and yet the Volume refuses to accept values and only supports some CC controllers, like number 22 in Mela's example.

I attach original file from Mela.

File attachments: 
Image icon auto-conex-mela.png
Binary Data Buss-Automation.qtz
14 February, 2024 - 21:02 — windowsrefund

I think I had to enable 'hook' in order to get the volume to work. I'd double-check but I'm on a different box right now. Also, it know I was able to get it to work using a CC other than 22. I believe I used 9 actually (or 3).

24 February, 2024 - 15:30 — windowsrefund

Does anyone know exactly how cc values 0-127 correlate to db values? I'm automating a volume slider on a bus. When I use a value of 100, it results in the volume being set to -0.2 and a controller value of 101 results in a volume value of 0.1. So really, there's no way for me to programmatically end up on 0.

24 February, 2024 - 17:35 — rncbc
rncbc's picture

not exactly,

but a maximum MIDI CC value of 127 should equal 0dBfs and a minimum of 0 to -inf(inity)dBfs (< -70dBfs on qtractor's meter display); to be exact, it's a non-linear conversion scale (logarithmic/exponential); for performance reasons, it's implementation follows a cubic approximation or a piece-wise linear standard curve (cf. IEC_Scale in qtractorAudioMeter.cpp).

byee

24 February, 2024 - 17:39 — windowsrefund

Yea, I was hoping the max cc of 127 would translate to 0 as well since I have "Logarithmic" checked. In my case, that resulted in +6db.

Add new comment

Copyright (C) 2006-2024 rncbc aka Rui Nuno Capela. All rights reserved.
Powered by Drupal