On January 27, 2012 8:41:17 PM Robert Jonsson wrote:
> Hey guys,
> Has this something to do with the change from NO to GM or?
Sure looks like it.
With song type other than NO, one must store program, volume, pan
at position zero.
On midi track info panel must select program, volume, or pan
and hit those 'store' buttons.
Too bad it's not really obvious that this must be done.
Flo's proposal of 'track' properties program, volume and pan
which automatically store always at position zero would fix that, but I'm
just not sure if we really need another set of redundant controls
possibly causing more confusion.
If we could just make it clearer to the user that they must actually store
something, at position zero or wherever, we wouldn't have to add
any more controls.
Sigh, I dunno, maybe we should remove those track info 'store'
buttons and make just automatically store at the current position.
But then the same would have to be done for the volume sliders, pan knobs,
and the three 'Var' 'Rev' and 'Cho' knobs. Also the pianoroll midi knob.
But those controls already have a right-click automation menu where
users can store the values.
I think the whole idea may have been to allow users to adjust values in
'NO' song mode without having to store anything. You know, just
to quickly get running.
But with this 'GM' default song type it's kinda messing things up.
But then, if we later remove this pesky song type like muse_evolution
as we discussed, this whole issue just might go away...
Or will it?
Even if we move this song type functionality into the instruments like
muse_evolution, do we still need to reset controllers upon rewind?
I'm thinking yes.
Why do we reset controllers upon rewind in the first place?
The idea was to reset the song to some defined initial state so that
it always plays the same regardless of what may have changed
/during/ the song such as program changes etc.
Without this, the user rewinds the song and hits play, but the song
sounds different because some controller had been changed during
the previous playing.
Consider: It becomes necessary because in song type 'GM', 'GS', or 'XG',
upon rewind MusE sends out appropriate sysexs to reset the instrument.
So after the sysex reset, all the device's controllers might be reset to
some unknown state, so that's one reason why we have to send out
/our/ controllers once again after that, to be sure.
Really it's up to the user exactly what is stored and sent out at position 0.
We just need to make them aware of that. Right?
I mean, it's one of the basic fundamentals of MusE currently...
> 2012/1/27 SourceForge.net <noreply@...>:
> > Bugs item #3480622, was opened at 2012-01-27 10:33
> > Message generated for change (Tracker Item Submitted) made by emrum
> > You can respond by visiting:
> > https://sourceforge.net/tracker/?func=detail&atid=604222&aid=3480622&gro
> > up_id=93414
> > Please note that this message will contain a full copy of the comment
> > thread, including the initial issue submission, for this request,
> > not just the latest update.
> > Category: Midi
> > Group: None
> > Status: Open
> > Resolution: None
> > Priority: 5
> > Private: No
> > Submitted By: Emanuel Rumpf (emrum)
> > Assigned to: Nobody/Anonymous (nobody)
> > Summary: fluidsynth - instrument changes on rewind
> > Initial Comment:
> > muse 2.0-rc2
> > reproduce:
> > - create a short midi-sequence
> > - load a soundfont with fluidsynth
> > - slelect fluidsynth and assign an instrument for the track
> > play.
> > everything ok, you hear the selected instrument
> > press reverse, or loop the sequence:
> > ==> the instrument changes, it is reset to piano - NOT ok