AU Value Bug

[uebe]

First of all: Thanks for the great software. I use it very often!!

I found a bug in the AU Version:
When the AU sends a ctr change to SL, SL sends back the old value (the value, that it had before the ctr change).
You can reproduce this by connecting a fader in Mainstage to a control (i.E. sync or rate) and change it in SL (OSC Interface). Mainstage will be always one step behind.

Possible cause:
The processing of the event in the _nonrt_update_event_queue is faster then the on in the _event_queue.
This leads to the signal ParamChanged beeing emitted bofore the new value gets wirtten to the ports. If this happens, the AU gets the signal and reads the old (yet unchanged) value.

Possible fix:
Send the signal from looper.cpp (works on my computer)
in looper.cpp

Code: Select all

         default:
            ports[ev->Control] = ev->Value;
               LoopParamChanged(ev->Control, _index); // emit
            //cerr << "set port " << ev->Control << "  to: " << ev->Value << endl;
            break;
         }

in engine.cpp (add_loop):

Code: Select all

   LoopAdded (instance->get_index(), !_loading); // emit
   instance->LoopParamChanged.connect(slot(*this, &Engine::parameter_changed));


in engine.cpp:

Code: Select all

void Engine::parameter_changed(int ctrl_id, int instance) {
   ParamChanged(ctrl_id, instance); // emit
}

in engine.cpp (mainloop):
disable the signal

Code: Select all

   //ParamChanged(evt->Control, instance); // emit


Greetings. Uebe

[jesse]

Yes, there is definitely a race condition there, good catch.

The problem with your solution is that the code in looper.cpp where you added the new signal LoopParamChanged is called from the realtime audio thread, and as a rule I don't emit signals from there, because the target may not be (and usually isn't) realtime safe code.

I'll have to think more about the best way to fix this one.....

[jesse]

OK, I found a better way to solve this, it will be in the soon to be released version 1.7.0.