Static (XML only) MIDI output not working correctly on Windows

Bug #360285 reported by Sean M. Pappalardo
2
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Undecided
Unassigned
1.7
Fix Released
Medium
Albert Santoni

Bug Description

When operating a MIDI controller using simple XML mappings to certain functions like rate_temp_up & cue_default, it looks like a valueChanged signal is not fired, evidenced by the GUI button and output mapping not responding. If I operate the control on the GUI, the on-screen button and the mapped output LED respond as expected. This is only a problem on Windows.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

On a first pass, I don't know why this is happening. MidiObjectWin does not handle emitting valueChanged. This is done by MidiObject -- and MidiObjectWin uses receive just like all other MidiObject's, so I don't see what would make this specific to Windows.

Does this happen no matter what? What if you build with script=0?

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

After extensive testing, it looks like the static (XML-only) output mappings are screwed up.
With midiscript=0: the buttons in question work correctly (they only do the noteoff color) if the mapping is loaded from within the preferences, but not when loaded at startup
With midiscript=1: the buttons in question don't work correctly at all, and if I load the mapping from the preferences (as opposed to startup,) other ones don't work! (Like Play, also only doing the noteoff color.)

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Crap, I meant: incorrect behavior means the buttons only do the note-off color. They work correctly with midiscript=0 and loading the mapping from the prefs.

Revision history for this message
Albert Santoni (gamegod) wrote : Re: [Bug 360285] Re: ControlObject valueChanged signals not fired when using MIDI on Windows

I have no idea what you're trying to say. First you were talking about
ControlObjects, and now you're talking about MIDI output.

Since this doesn't have anything to do with scripting (you said it was
a static mapping problem), only test with midiscript=1. Turning
scripting off is probably exposing a separate bug that you're seeing.

Can you clarify exact what isn't working here? Are NOTE_OFF messages
not being sent as output properly? Also, can you change the title of
this bug to reflect whatever you think the problem is? :)

Thanks,
Albert

On Tue, Apr 14, 2009 at 10:03 PM, Pegasus <email address hidden> wrote:
> Crap, I meant:  incorrect behavior means the buttons only do the note-
> off color.  They work correctly with midiscript=0 and loading the
> mapping from the prefs.
>
> --
> ControlObject valueChanged signals not fired when using MIDI on Windows
> https://bugs.launchpad.net/bugs/360285
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

summary: - ControlObject valueChanged signals not fired when using MIDI on Windows
+ Static (XML only) MIDI output not working correctly on Windows
description: updated
Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Sorry, this has been confusing. At this point, it looks like note_on or note_off messages are not being sent (that is, one but not the other) when I operate buttons on the MIDI controller, but only for certain controls:
rate temp up, no note_on
play, no note_on (sometimes)
rate temp down, no note_off
Cue default, no note_off

Revision history for this message
Albert Santoni (gamegod) wrote :

Possible fix applied in r2383. Please test!

Thanks,
Albert

Revision history for this message
Albert Santoni (gamegod) wrote :

Just to follow up, on Linux, I can confirm:
1) When I push a button on my controller that's mapped to rate_temp_up, the GUI responds by moving the slider + highlighting the rate_temp_up button, and the controller responds by lighting up the corresponding LED that I mapped statically. The engine also responds by pitch bending the waveform/audio.
2) When I click the rate_temp_up button in the GUI, the engine responds properly (pitch bends waveform/audio), and the controller's corresponding LED lights up correctly.

This is using a test XML file on Linux that does not use scripting at all. (Tested on SCS.3d.) These test cases cover what Sean said he was having problems with on IRC:
==========
<asantoni> ok
 so I'm going to map that to rate_temp_up
 the LED
<Pegasus_RPG> ok
<asantoni> and then toggle the button in the GUI?
<Pegasus_RPG> no
 that worksd
 it's when you toggle the control from the controller
<asantoni> ok, what doesn't work
 ok
<Pegasus_RPG> neither the GUI nor the controller light ractos
 but the function happens
<asantoni> like under the hood
<Pegasus_RPG> yes
<asantoni> it pitch bends?
 ok
<Pegasus_RPG> the pitch slider moved
<asantoni> that is strange
 oh
 ok
 yeah hmm
 rate_temp_up could be coded strangely
<Pegasus_RPG> but the temp up light doesn't light on the contoller or the GUI
==========

If Sean's problem persists, then I think it's either:
1) A Windows-only problem (either MIDI or ControlObject-related. The fact that the GUI doesn't respond when he pushes a button on his controller suggests one of these two.)
2) Scripting-related (could be messing up the state of the device)

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

It works alot better now, though I still have to load the mapping again in the prefs before the outputs work. (Do the MidiLEDHandlers get created on startup?)

Revision history for this message
Albert Santoni (gamegod) wrote :

Ok, thanks.

Please run Mixxx and post all of Mixxx's console output from a fresh startup...

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Attached is the console output from running Mixxx when it loads MixxxMIDIBindings.xml, then I reload the SCS.3d static XML mapping, after which the outputs work.

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Attached is the static mapping file I'm testing with. (It's not complete but is fine for testing.)

Revision history for this message
Albert Santoni (gamegod) wrote :

I was able to reproduce your problem where the static output mappings would not work until you reloaded the mapping in the prefs, using your attached SCS.3d mapping file. A fix for it is in r2390, please test!

Thanks,
Albert

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Tests good for me with the SCS.3d. (Will test with the .1m late this week.)

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Tests good with the SCS.1m too but there are other issues which I'll put into a new bug.

RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: New → Fix Committed
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5133

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.