On July 25, 2012 7:30:54 PM Tim E. Real wrote:
> On July 24, 2012 2:31:38 AM Tim E. Real wrote:
> > ----------------
> > Remove the song type:
> > As we discussed before, you should look at muse_evolution to see how it
> >
> > was removed. All the sysexes were moved into the instruments.
> >
> > Our instrument editor sysex editor needs to be completed first.
> > I may try to do that for you. It was long-promised and overdue.
OK this is finished here. The Instrument Editor's Named Sysex editor
works now and has a comment pane added. Storing/loading them in the
instrument file works. Adding/editing/deleting named sysexes works.
Shall I commit it or did you have some other direction in mind Florian,
or is it helpful? After all, that sysex editor panel was dead for so long,
so at least /that/ works now...
It's harmless ATM, it just let's you create them but nothing else.
OK so far so good. We can make *named* Instrument sysexes.
But now the question is: What do we do with these named sysexes?
They are stored in the MidiInstrument::_sysex member.
Been studying the situation and reading up on these 'mode' sysexes.
Take XG for example: To turn on XG mode, A 'GM on' sysex is sent,
then an 'XG on' sysex.
It may be required to wait a small amount of time between these two,
and between these types of 'mode' sysexes and the start of notes
because some hardware might need time to setup.
I've been reading about so-called 'setup bars' where it is common
practice to reserve bar 1 for such time-sensitive operations,
and all notes start at bar 2 or later.
What I'm getting at is, if we are to have time-delayed init events at
the start of songs, we can't allow notes to be placed among them,
and we should try to enforce a 'bar 2' notes starting point policy.
Or else... we make a 'pre-bar' which plays before the song proper starts.
But... Similar to our defunct 'pre-count' bars, this might be very hard.
Currently one can place these sysexes into parts, yes, BUT if
you change the track port or port's instrument MusE will still send
out these part sysexes, possibly to a chosen device which doesn't
support them. So that's not good, better to keep these init sysexes
within the instruments so no harm if one changes a port's instrument.
So... We have a few other Instrument members at our disposal:
EventList* _midiInit;
EventList* _midiReset;
EventList* _midiState;
char* _initScript;
1) _midiInit:
Believe it or not, this actually works now.
Instrument files can define a sequence of init events and MusE
will send them to the device at start or rewind to position 0.
Here's the good part: These init events take /priority/ over Song Type.
If MusE finds any init events in the instrument, it sends THEM
and NOT the built-in sysexes for turning GM, GS, and XG on
depending on Song Type. See midi.cpp : Audio::initDevices().
I have come to understand that /this/ list is where all the action will
now be focused if we remove Song Type.
What we need is to be able to edit the init list and, as I understand it,
these new named sysex editing facilities help define just exactly what
sysexes are available from the instrument. From the available sysexes,
one would 'compose' an init sequence.
The available sysexes would also be displayed in the event list editor
so users can pick ones to put in the song. No more hand-editing in
the list editor, except in cases where a sysex has variable bytes,
so the user would pick such a sysex from the available ones and then
'fill in' the variables in the list editor.
Now... What editor can we use to edit this instrument init list?
Naturally, our Midi List Editor would seem the most logical choice.
But... It takes a part list and is based on MidiEditor which deals with
/parts/ and /tracks/.
So we may have to instead put a custom sequence editor right into the
Instrument Editor on a new tab called 'init' or 'scripts' or something.
2) _midiReset:
Similar to _midiInit, events defined here would be sent whenever
Midi->Reset is clicked. It is not used ATM, but Reset coding could
be easily changed to use it.
3) _midiState:
Reserved for internal use, user ideally shouldn't be able to edit.
It stores the state of various synths, and dssi-vst chunks for example.
4) _initScript:
This intriguing member is totally unused but is loaded and stored
in the instrument file. Muse-evolution does not have it I believe.
I guess the usage is wide open here. What scripting - Python?
Integrate with our Python support?
---
What I was hoping for is that different init sequences from /multiple/
init sequences per instrument could be available and chosen by the user.
In other words "My instrument is XG but I want the GM mode".
Unfortunately, it looks as though currently separate multiple instruments
will have to be defined - one for each desired 'mode', because it is
possible all the patch names need to be different and so on.
So in this case of XG, if one wants GM mode, one would NOT choose the
XG instrument file, one would choose the GM file. This is mostly OK,
but my fear is that some devices may not have exactly the same
patch/drum names/sounds as true GM. So that's why I really wanted to
keep all this mode switching stuff together inside the one instrument.
After all, I'd really rather know that my chosen instrument is in fact
an XG instrument in GM mode and know the /exact/ patch names, rather
than just selecting the plain GM instrument.
--
Lastly, we have the midi file importing and exporting.
Our Song Type is /strongly/ linked to the midi file 'mode' sysexes.
You have seen how our import code looks for GM, GS, or XG On
sysexes in the midi file and chooses the appropriate GM, GS, or XG
instrument for the ports used, also depending again on Song Type,
and may in fact set Song Type based on what it finds.
Without Song Type I can see this still working OK, I think.
But what about exporting? If we have a GM, a GS, and an XG instrument
all in use in the song at the same time, which appropriate sysex
do we export to the midi file? Especially with a single-track format-0 file.
With a Song Type it is easy. Without ... ? Must research a bit more -
not sure about multiple devices, multiple tracks etc.
Whew. All for now. Comments encouraged. Will study situation some more.
Cheers. Tim.
> > But you know, it's been a while since I looked at this but I recall there
> >
> > were problems and questions even with evolution's approach.
> >
> > I remember questioning "how is this going to work?"
>
> Darn, I knew it. Building muse-evolution now I get compile errors and
> immediate runtime crash.
>
> Try it now if you wish, Florian.
> * Here ya go! First commit to this puppy in how many years?
>
> - Fixed some compile errors and runtime crashes.
> - Don't build awl/ltest - has undefined link refs to QDom stuff. FIXME!
> -Fixed Plugin::Plugin() crash due to null fi passed by AuxPlugin.
> Wha...? It worked before.
> -Fixed compile errors: Added <sys/types.h> and <sys/stat.h> at top of
> dssihost.cpp
>
> -------
> Reviewing muse-evolution right now. It's been a while.
> I want to re-learn the mechanism by which an instrument's
> mode can be changed, if at all, before I attempt any work.
>
> Robert, do you have any recollection on what the goals/mechanisms
> for instruments and 'modes' were in evolution?
>
> Some midi instruments support different modes, emulations etc.
> Looking at evolution's GM .idf file, it has a "GM on" sysex.
> The GS, and XG .idf files have "GS on" and "XG on".
>
> But don't GS and XG instruments allow emulation of GM mode?
> If so, why are there no sysexes for them in the GS and XG .idf files,
> and even if we were to add them,
> * by what mechanism would one choose the mode?
>
> In muse2, that's what Song Type allows! Set a GM mode on an XG instrument.
> But currently MusE2 just blunt-force blindly sends out the sysexes
> regardless of instrument.
>
> ...
> OK I just tested, and muse-evolution does not even appear to be
> sending out these instrument 'mode' sysexes. Nor will selecting
> reset or init from the Midi menu, they seem dead.
> Yeah, I thought there was something a bit odd about its design.
> It's unfinished, eh? Or am I doing something wrong?
>
> So we have some planning to do. Maybe Flo is already on this,
> but if we move these 'mode' sysexes into the instruments just like
> evolution, then don't we we need a combobox on each trackinfo to
> select the various instrument modes? And add "GM on" sysexes to the
> GS and XG instrument files as mentioned above, so that they can be listed?
>
> Must research a bit more, not sure how much is true there about GS, XG
> modes. Maybe it's simply "init" for GM mode, then "XG on" for XG mode.
>
> I will continue with attempting to bring our instrument sysex editor to
> life, and maybe add the sysexes to the idf files just like evolution, maybe
> adding the "GM on" to GS and XG so that they can be listed.
>
> Cheers. Tim.
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
