On 2017-05-16 01:02 AM, Andrew Deryabin wrote:
> Hi guys,
>
> I want to ask you about something strange or may be it's only something
> with my memory?
>
> Background: I created a project with yoshimi as main softsynth. For one
> channel I set mode to 'mono', checked 'portamento' checkbox.
>
> Some time (1-2 days) everything was working just right. But after some
> saves I noticed that portamento stopped working after opening the song.
>
> Investigating this I found the following: At some point muse added
> controllers 120 (all souns off) and 121(reset all controllers) to every
> midi port entry in saved song's med file. It was very strange, because I
> (may be) can't remember that I've ever added these by hand.
>
> As a result when song opens, muse sends these controllers to every midi
> port (and to softsynths too).
>
> Yoshimi is reacting to controller 121 by resetting all parameters
> (portamento checkbox, portamento time) - some of them are rarely used
> dynamically.
>
> So my question is: Is this behavior normal or not?
MusE will silently add controllers for controller events
/arriving/ at an active in-use midi port.
Those two controller events may have arrived from
outside and MusE duly created controllers for them.
Nah, that can't be it - all 16 channels sent from outside?
It may be this:
Does the midi port section of the song file look like this:
<midiport idx="0">
<defaultInChans>1</defaultInChans>
<defaultOutChans>1</defaultOutChans>
<name>M Audio Delta 1010LT MIDI</name>
<channel idx="0">
<controller id="120">
<val>0</val>
</controller>
<controller id="121">
<val>0</val>
</controller>
</channel>
...
... a further 14 channels ...
...
<channel idx="15">
<controller id="120">
<val>0</val>
</controller>
<controller id="121">
<val>0</val>
</controller>
</channel>
</midiport>
Andrew, see Audio::panic().
Did you possibly hit it?
It is the *only* place that could do that,
other than from external events arriving.
I could not get the problem to occur...
Until I hit Panic !
Hmm. Maybe we should not use sendEvent() there,
using others like possibly putEvent() so that the
'current value' of all the ports is not disturbed.
Would that be better?
After all, panic is sort of a special command, we don't
necessarily want those two CTRL_ALL_SOUNDS_OFF
and CTRL_RESET_ALL_CTRL value of 0 hanging around.
And yeah, notice with those two a value of 0 is all that is
required, not a value of 1, to activate the commands
in the receiving devices. Hm, not too good, eh?
Hm, which method to call instead...
One easy (easier) solution is that in Audio::Panic(),
/after/ those two sendEvent() calls, call them /again/
with CTRL_VAL_UNKNOWN instead of value 0.
Like this:
port->sendEvent(MusECore::MidiPlayEvent(0, i, chan,
MusECore::ME_CONTROLLER,
MusECore::CTRL_ALL_SOUNDS_OFF,
CTRL_VAL_UNKNOWN), true);
port->sendEvent(MusECore::MidiPlayEvent(0, i, chan,
MusECore::ME_CONTROLLER,
MusECore::CTRL_RESET_ALL_CTRL,
CTRL_VAL_UNKNOWN), true);
...so that the song will ignore the controllers upon saving.
Yes, I think that is the /required/ solution. Whacha think?
Shall we try it?
Tim.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
