You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the merge of Tom's MIDI branch, the following patch came to my attention, I noticed that this method replaces a thread safe call to ControlObjectThread with a direct call to a ControlObject->setValue (p is a ControlObject).
Using the cot implementation breaks all midi branch learning / debugging mode code, so I merged in the p->setValue...
This bug is to note this fact and encourage a look at this to determine if this behaviour is safe, and if not to replace it with something safe.
Index: src/midiobject.cpp
===================================================================
--- src/midiobject.cpp (revision 2398)
+++ src/midiobject.cpp (working copy)
@@ -204,10 +221,7 @@
// I'm not sure entirely why buttons should be special here or what the difference is - Adam
if (((ConfigValueMidi *)c->val)->midioption == MIDI_OPT_BUTTON || ((ConfigValueMidi *)c->val)->midioption == MIDI_OPT_SWITCH) {
- ControlObjectThread cot(p);
- cot.slotSet(newValue);
-
- //p->setValueFromThread(newValue);
+ p->set(newValue);
// qDebug() << "New Control Value: " << newValue << " (skipping queueFromMidi call)";
return;
}
The text was updated successfully, but these errors were encountered:
This was fixed by Albert (removing the special case for buttons) and then myself (implementing proper conversion of Button up/down to NOTE_ON/OFF) in trunk shortly before the branch for 1.7.0 . It won't be fixed in any release of 1.6.x.
Reported by: deftdawg
Date: 2008-11-27T03:41:10Z
Status: Fix Released
Importance: Critical
Launchpad Issue: lp302684
Tags: midi
During the merge of Tom's MIDI branch, the following patch came to my attention, I noticed that this method replaces a thread safe call to ControlObjectThread with a direct call to a ControlObject->setValue (p is a ControlObject).
Using the cot implementation breaks all midi branch learning / debugging mode code, so I merged in the p->setValue...
This bug is to note this fact and encourage a look at this to determine if this behaviour is safe, and if not to replace it with something safe.
The text was updated successfully, but these errors were encountered: