On July 27, 2012 9:14:45 PM Tim E. Real wrote: > 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.
Instead, not a complete 'bar 1' or a 'pre-bar' but simply a timed execution of the sequence of init list events, each at their prescribed event time. As soon as the last event is sent - we're ready to roll from bar 1. (We inform Jack that it is now OK to roll the transport, via our 'slow sync' client callback. This is our desired transport 'waiting' mechanism). So init will happen as quickly as possible, determined by the init list event times. It has to - it needs to be executed each time the transport is rewound, or possibly even re-started (see below). One problem: The very last event: If there needs to be a delay between the last event and the start of the song (start rolling), how do we do it? I propose one extra event past the list end as an "end" marker - a sort of dummy noop event like a blank sysex or other event. The code which executes the sequence will finish the sequence on that last /marker/ event. As long as we have that last event's time we are good to go. Then we are truly ready to roll the song, from bar 1. Sound OK? I think it can work. Stumbled across Logic manual. Was reading about 'chasing' settings, that is, what or what not to send when starting playback from the /middle/ of a song (and I presume from start and when seeking). It has lots of options, even allowing init to be sent each time. Interesting stuff. Tim. > 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
