Hi folks i'm still alive :) (or "again"?)
finally got around to read all the old MusE mails, phew ;) tim, please commit your changes if not done already > 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. isn't the purpose of GM that there ARE no different patch names? GM instruments shall have the same patches, don't they? btw, having multiple idf files for the same instrument type in different modes is okay to me, if there are no huge redundancies. if there are redundancies, i'd let muse read ONE idf file and create internally multiple instruments, that would be the easiest. (that is, multiple sections in that file with information like "just for GM mode", "only for XG or GS mode", "for all modes" or "for fnord mode") > Lastly, we have the midi file importing and exporting. 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. ask that the user in the export/import dialogs, possible make sane defaults (count all GMs, GSs and XGs, and preselect the type which is represented most often). exporting is tough, we probably MUST ask the user there, right? > 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). yes, agreed. > 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? we just make a delay, like between the events? a dummy noop event sounds good ad "enhancing song-changed-flags to 64bit": good thing, +1. i have not read nor understood your latest mail about latency, but still two things about that: - would my prerecording feature help? this would allow you to run jack with low latency all the time; however, each change in a cpu-intensive track will require you to pre-calculate (=cache!) a lot (more than just 0,5 seconds). but that would me a nice enhancement to this feature xD - just add a buffering option to muse? e.g. implement a "fake" jack driver which behaves like a jack server, but in fact only fills data into a large (~1 sec) buffer, which is then read by another real jack thread? > 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? try what exactly? /branches/attic/whatnow? > 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? i've nothing to do with sysexes (yet). i honestly don't get half of the discussion about them ;) just go ahead, i trust you'll make me happy :D greetings flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
