View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000219 | OpenMPT | Playback Compatibility | public | 2012-02-13 08:22 | 2012-03-08 11:10 |
Reporter | christofori | Assigned To | Saga Musix | ||
Priority | low | Severity | tweak | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | x86 | OS | Windows | OS Version | XP |
Product Version | OpenMPT 1.19.04.00 (upgrade first) | ||||
Target Version | OpenMPT 1.20.01.00 (upgrade first) | Fixed in Version | OpenMPT 1.20.01.00 (upgrade first) | ||
Summary | 0000219: Portamentos processed even if channel is muted | ||||
Description | While it likely won't cause issues for many/any (and isn't even a problem for me yet)... I'd better give a bit of background first. As I use EWQL Play for some instruments and as it's VST hasn't really been wonderfully received within OMPT I've been using other VSTs (Midibag's VST2MID and/or one called jthalmus (it and others available at http://www.jaltoh.6x.to/) to output channel data across the MIDI bus of my soundcard for both Play's benefit and for lighting control (w00t! I can run my lights from within the tracker!! muahaha..). Anyway, in doing all of this I've also set up MIDI-OX to allow input from my "normal" MIDI controllers.. and it's become somewhat common practice for me lately to leave the Output monitor window open in MIDI-OX (else I would never have caught this behavior). It should also be noted that I'm essentially running a MIDI loopback from the OUT of my card to the IN so that I can set the VST in the tracker to output to the MIDI card, and set Play to receive MIDI from the same card. Now then.. in one of these channels I'm using to control a Play instrument, I use portamentos in the volume column for some pitch bends (tone portas done thusly are output via the VSTs as pitchbend controls). When the channel is muted I notice that the pitchbend events are still being processed (as portas in OMPT) and are being sent out, though nothing else is (that I've seen yet...). Normally this shouldn't cause anyone any problems, unless they've set more than one channel up to control the same MIDI channel -- for some reason.. but anyway, it COULD cause something of a headache to someone down the line. Listing this as a 'tweak' in hopes that it's a fairly simple change to make. :) FYI: I have tried both with and without the option "Ignored muted channels" enabled, and have tried multiple "VST2MID"-like plugins to ensure it wasn't plugin behavior. Also interesting -- each time a module that uses one of these VST2MID-type plugins is closed, a "CC: Pedal (Sustain)" event shows up on every MIDI channel in the MIDI-OX output monitor. Others (such as "Reset Cntrl, All Notes Off, All Sound Off") I understand being in the close code.. but why the sustain pedal (MIDI CC64)..? | ||||
Steps To Reproduce | Create a new file. Add VST2MID or jthalmus as a plugin. Create a new instrument using no samples, set it to use the MIDI plugin loaded and any appropriate MIDI channel. Then set the VST to output to your MIDI controller. Enter some notes in a channel, being sure to use some tone portamentos in the volume column. Use some program (MIDI-OX perhaps) to monitor the in/output of your MIDI controller. Note how when the channel in OMPT is NOT muted, all events show up in the output monitor (as they should..) but that when muted, ONLY the "pitch bend" events show up (as they should not..!) | ||||
Additional Information | I realize this is likely not a problem for anyone, and understand if it gets put waaaaay down in the queue.. ;) | ||||
Tags | No tags attached. | ||||
Has the bug occurred in previous versions? | Likely, but not confirmed. | ||||
Tested code revision (in case you know it) | |||||
I guess there are good reasons for applying and not applying portamento on muted channels - as it's a per-channel thing, you could have notes on other channels that are affected by the portamento and thus won't be bent anymore. But then again, why should they be affected by something that's happening on a muted channel? As for your off-topic question, there are happening quite a few things when a track is stopped, but why this particular CC is sent, I have no idea. I just assume that various properties are reset to their defaults. |
|
Revision 1181 disables MIDI portamento on muted channels. Please check http://sagagames.de/stuff/mptrack.exe |
|
i believe i obtained this rev. via the testing update check prior to seeing the link here; though just in case they somehow were different i downloaded/tested both... the PORTAMENTOS BEING SENT WHEN THE CHANNEL IS MUTED issue still exists. (edit -- the cc64 stuff was an odd attempt at humor I s'pose.. sorry for the confusion.) o:) |
|
Well that is not the original issue - please open one issue per bug report please. I only fixed pitchbend handling. |
|
Updated to 1.20.00.69 testing and can confirm the issue still exists there. |
|
Please provide a minimal test case (preferrably with free VSTs) where portamento is processed when it shouldn't. |
|
Allright. Download "jthalamus":
place the dll into your VST folder. Open OMPT and create a new OMPT module (have not tested with other formats yet..). Add jthalamus as plugin 1 (after of course adding it to your plugin mgr..) and then edit the plugin parameters. On the input tab, we're only concerned with MIDI messages being sent from the tracker; ensure "Receive midi from host" is checked. Right-click somewhere inside the VST for it's own context menu and ensure "Log input data" is checked. Don't worry about a valid output MIDI device or any other options; just leave jthalamus open on the Input tab. In OMPT, make an instrument. I usually clear the samples but if it's an empty MPTM file you shouldn't have to. Set your instrument to use jthalmus on MIDI/VST channel 1.In a new pattern enter a note or two. After one of the notes enter some porta commands in the volume column. You should now have something similar to the following: 1 C-5 01 .. ... Play the track. Notice the input window of jthalamus logs the data as it happens. Now, mute the channel you just put that into. Play it again. Nothin.. ah, wait. There's the porta commands that are supposed to be muted. |
|
And yeah.. I've tested other MIDI out VSTs and other loggers to ensure it's not just jthalamus. ;) I'm wondering if it's just porta commands in the volume column that are being sent -- nope, no matter which column (note or effect) the MIDI signals are sent upon OMPT's processing of the portamento commands. :/ |
|
You must be confusing something here - the pitchbend events that I receive here are those when explicitely closing or opening input - in which case pitch bend is reset to centre, all notes are killed, etc... The actual pitch bends in the pattern are not transmitted anymore. All you should see in jthalamus is
For all 16 MIDI channels. |
|
Nope... no confusion here. Appologies for the time taken to respond. :) For your reference, i've taken logfiles using MIDI-OX of a pattern's playback which contains this issue... and though i've used MIDI-OX here, i can still confirm as well that using ONLY jthalmus as i previously advised, the issue is still present. Here are the logfiles: http://christofori.net/ompt-play/ In that folder you will find 3 files applicable to this issue:
For reference, the output monitor was cleared between each log and/or screenshot to ensure no "junk" from previous tests was logged or visible. The pitchbend events still exist. |
|
I think the problem only happens for channels that were already active (sending note data to the plugin) when muting them. Can you confirm that the problem doesn't occour when first muting all channels and then restarting playback? |
|
Yep -- that's what i've done each time. i generally mute/unmute channels prior to beginning playback.. though for fun, i've just now tested the following 3 scenarios: 1) Muting ALL channels before playing back a pattern [using F7 / "Play pattern from start"] containing portamentos->MIDI Pitchbend; In the first two cases, as soon as rows are processed the MIDI data is generated. In the third case, however, NO MIDI data is sent..! After running a few more tests, it appears that the pitch bend MIDI data is sent while the channel is muted only if the song is not played from the beginning ("Play Song from Start" option). Somehow, when "Play Song from Start" is initiated, this causes OMPT to recognize the muted channel's status and the MIDI events are not sent. That oughtta help..! :) Even when clicking onto another order from the one currently playing -- so long as playback was initiated from the module beginning (ie: F6 is the default button i believe -- aKa the "Play Song from Start" option) the MIDI pitchbend data is NOT sent. [[Now that the problem's appearance seems to be traceable, i offer my appologies for leaving out the fact that apparently, i had been playing back from either a current row or the current pattern (or, sometimes using the "Play pattern from start" [or F7] option..) ^_^ i thought i was already being exceptionally nitt-picky, but fell short on that one small detail..]] |
|
noticed .74 go up -- tested; and results are better -- however, if one mutes the channel in question and plays the pattern (F7) it works the FIRST time -- then if you unmute the channel and re-mute it, the pitchbend data is sent again. :/ |
|
I didn't change anything related to MIDI pitch bends in .74 - but I can imagine where the inconsistent behaviour comes from and I'll check it out soon. |
|
Ok, revision 1210 / OpenMPT 1.20.00.76 should really fix the issue. |
|
Threw everything at this one which i could conceive of, to test -- and as near as i can figure, it ain't broke no more. :) Confirmed fix. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2012-02-13 08:22 | christofori | New Issue | |
2012-02-13 09:05 | Saga Musix | Note Added: 0000604 | |
2012-02-14 21:49 | Saga Musix | Note Added: 0000605 | |
2012-02-14 21:49 | Saga Musix | Assigned To | => Saga Musix |
2012-02-14 21:49 | Saga Musix | Status | new => feedback |
2012-02-14 21:49 | Saga Musix | Target Version | => OpenMPT 1.20.01.00 (upgrade first) |
2012-02-15 05:17 | christofori | Note Added: 0000606 | |
2012-02-15 05:17 | christofori | Status | feedback => assigned |
2012-02-15 08:31 | Saga Musix | Note Added: 0000607 | |
2012-02-15 13:27 | christofori | Note Edited: 0000606 | |
2012-02-19 09:59 | christofori | Note Added: 0000608 | |
2012-02-19 12:52 | Saga Musix | Note Added: 0000609 | |
2012-02-19 22:24 | christofori | Note Added: 0000610 | |
2012-02-19 22:25 | christofori | Note Added: 0000611 | |
2012-02-19 22:28 | christofori | Note Edited: 0000611 | |
2012-02-20 22:52 | Saga Musix | Note Added: 0000612 | |
2012-03-06 12:26 | christofori | Note Added: 0000615 | |
2012-03-07 00:37 | Saga Musix | Note Added: 0000616 | |
2012-03-07 03:24 | christofori | Note Added: 0000617 | |
2012-03-07 03:25 | christofori | Note Edited: 0000617 | |
2012-03-07 08:51 | christofori | Note Added: 0000618 | |
2012-03-07 13:34 | Saga Musix | Note Added: 0000619 | |
2012-03-08 00:14 | Saga Musix | Note Added: 0000636 | |
2012-03-08 00:14 | Saga Musix | Status | assigned => feedback |
2012-03-08 05:04 | christofori | Note Added: 0000642 | |
2012-03-08 05:04 | christofori | Status | feedback => assigned |
2012-03-08 11:10 | Saga Musix | Status | assigned => resolved |
2012-03-08 11:10 | Saga Musix | Resolution | open => fixed |
2012-03-08 11:10 | Saga Musix | Product Version | OpenMPT 1.20.00.* (old testing) => OpenMPT 1.19.04.00 (upgrade first) |
2012-03-08 11:10 | Saga Musix | Fixed in Version | => OpenMPT 1.20.00.* (old testing) |