[Lmuse-developer] Added controllers - bug or a feature?

[Andrew Deryabin]

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?

[Tim]

Post by Andrew Deryabin
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.

[Tim]

Post by Tim
port->sendEvent(MusECore::MidiPlayEvent(0, i, chan,
MusECore::ME_CONTROLLER,
MusECore::CTRL_RESET_ALL_CTRL,
CTRL_VAL_UNKNOWN), true);

Duh, port->setHwCtrlStates() not sendEvent().
Yeah, that's it I think.
It's late... I can check tomorrow.

[Andrew Deryabin]

Hi Tim!

Post by Tim

Post by Andrew Deryabin
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?
<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>

Yes, I have the same thing!

Post by Tim
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 !

Now I remember, that I sometimes use this button when notes stuck.
That's it! Thanks, Tim.

Post by Tim
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.
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?

Yes, I think so. It's not good to add controllers with zero value - some
of them can be very destructive (like 'reset all controllers' in my
case) and should not be saved and restored with song.

P.S. There is one more interesting question - how one can remove that
saved controllers from the song and resave it? Only with `sed` ?

Regards,
Andrew

Post by Tim
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
https://lists.sourceforge.net/lists/listinfo/lmuse-developer

[Tim]

Post by Andrew Deryabin
P.S. There is one more interesting question - how one can remove that
saved controllers from the song and resave it? Only with `sed` ?

Sorry for late reply. There are two ways.

1: Open a pianoroll or drum editor
on a part in a track which uses one of the ports and
manipulate the control knob pane for each of those
two controllers. Then, do the same for all the other 15
channels.

2: Hand-edit the song file.

Yeah I know. Both are ugly. Fear not: After this fix
it should remove them all - if you hit panic one time.
Meh, not good enough. I will also check on song load
and try to silently IGNORE them from the file. These
two are special and do not belong there.

About the fix: Well there's more to the story.
MusE needs to do some more stuff after those
two messages are sent, to make sure its
internal representation of ALL controllers
is correct.

I thought of a few complications along the way.
Like... what happens if the user adds these controllers
to the pianoroll/drum controller graphs, and then
turns the knob - do we force it back to 'unknown' after.
And if they draw graphs on those controllers, well,
we basically have to honour that. Unless we define
a new flag for all controllers called 'One-shot'
meaning user must 'toggle' the graph value
or at least draw 'spikes' like the velocity spikes.

Also, after review I see the code that menu item
Midi > Reset Instrument calls was overlooked when I
did the zero-velocity note-on fixes a while ago.
I need to tidy it up.

Stay tuned. T.

[Tim]

Howdy, still here. Still working on this,

hope to have something soon, things were very slow

at first but making progress now.

T.

Post by Tim

Post by Andrew Deryabin
P.S. There is one more interesting question - how one can remove that
saved controllers from the song and resave it? Only with `sed` ?

Sorry for late reply. There are two ways.
1: Open a pianoroll or drum editor
on a part in a track which uses one of the ports and
manipulate the control knob pane for each of those
two controllers. Then, do the same for all the other 15
channels.
2: Hand-edit the song file.
Yeah I know. Both are ugly. Fear not: After this fix
it should remove them all - if you hit panic one time.
Meh, not good enough. I will also check on song load
and try to silently IGNORE them from the file. These
two are special and do not belong there.
About the fix: Well there's more to the story.
MusE needs to do some more stuff after those
two messages are sent, to make sure its
internal representation of ALL controllers
is correct.
I thought of a few complications along the way.
Like... what happens if the user adds these controllers
to the pianoroll/drum controller graphs, and then
turns the knob - do we force it back to 'unknown' after.
And if they draw graphs on those controllers, well,
we basically have to honour that. Unless we define
a new flag for all controllers called 'One-shot'
meaning user must 'toggle' the graph value
or at least draw 'spikes' like the velocity spikes.
Also, after review I see the code that menu item
Midi > Reset Instrument calls was overlooked when I
did the zero-velocity note-on fixes a while ago.
I need to tidy it up.
Stay tuned. T.
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/lmuse-developer