On Sun, Jan 16, 2011 at 4:12 PM, Christian Schoenebeck <schoeneb...@software-engineering.org> wrote: > On Saturday 15 January 2011 23:02:14 alex stone wrote: >> Is there an important (potentially destructive) reason why bank (MSB) >> + (LSB) data is separated from PC data going into linuxsampler, and >> the bank data is not queued with with the program change data in the >> ProgramChangeQueue so all 3 data type events are sent at the same >> time? > > There was probably not really a reason that those were splitted. Its been a > long time. I think there was one point in the past where the program change > part wasnt queued either and I *think* later just the program change part at > least was then queued due to necessity. Maybe we havent seen a reason to > change the code regarding banks select and queue those informations as well. > > And even now when I review it, I dont see the practical relevance. This > implementation detail should only be relevant if you send multiple subsequent > program change events on one and the very same engine channel within a very > short time (e.g. 2 subsequent program change messages on engine channel 1 > within couple miliseconds). Do you do that and if yes why? Or what am I > missing? > > CU > Christian >
Christian, thanks for the reply. We've done some further work and will send a patch for your perusal shortly. The use case is sending an entire song's worth of PC changes in advance of starting playback. The old use case was having to play a song more than once to trigger PC events which LS would then load. At each pass of the song, LS would pick up more of the events, until after 3 or 4 passes, the song would play correctly. We're now able to trigger a scan of the song, in advance of playback, send all scheduled PC events (including banks) before playback has started, wait a couple of minutes while everything loads, then hit playback and everything plays as it should. A significant timesaver. We've tested the patches we wrote, against a current CVS of LS, in linux (only), and the process now works satisfactorily. This was as much about modifying our code, as it was tweaking LS, so we needed to tackle both at once. Using this process of loading events before playback, we found a few instances where we were sending events for a single Engine Channel within a very short space of time, so taking further and even more robust testing into account this week, it seems to be working ok so far. We haven't encountered any obvious problems created in LS as a result of the changes, but we'd appreciate any further input or advice you might have, once Andrew has assembled and created the patches he'll then send to you. (He's in a different timezone, so he'll get to this once he's up and about) Alex. ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
