Greetings Alex! My reply may be more of a 'work around' than a definitive answer to your question, but it may prove useful.
I'd imagine that if you could basically split the bank/program change messages and sending them one after another with say, a 5 second interval (Say, banks first and then the related program change), it could mean that the buffer wouldn't overflow and lose the messages. Then again, you may have already thought of this and discarded it, but personally, it's how I would go about doing it. Andrew. On Fri, Jan 14, 2011 at 7:55 PM, alex stone <compos...@gmail.com> wrote: > Evening all. I have a question regarding the jackmidi buffer size in LS. > > Our use case. > > When we run a big orchestral song, and that song contains many program > changes, they are fed to LS through multiple jackmidi ports. This > works well, and LS is able to keep up with the steady, timed, influx > of bank and program change events. After a few passes over the song > with playback we have all the gigs loaded that we require and the > song, obviously, plays them correctly. > > In order to speed up the Bank and PC loading, and importantly, reduce > the number of passes over the song to 1, we're developing a PC > "loader". We open the project, press the button marked PC, and the > loader scans the song, reads the bank and program changes, and then > feeds them to LS to being loading, before we've commenced any > playback. This is intended to enable us to begin the loading process, > and after a little time, start playback, with all PC's performing > correctly, and the right samples being played back, the first time. > > We've run into a challenge where the action of squirting all those PC > messages at LS at once is failing. OOM2, our sequencer, is sending the > messages out ok, complete with all bank and patch data, as verified by > a midi monitor. But when it arrives at LS, the PC's are there, but the > bank data is not. We assume this is because we're overflowing the > input with too much information at once. > > > So, can i ask how the size of the jackmidi buffer is determined? Is it > "read" from the jack buffer size? Or is there an arbitrary size limit > for each LS jackmidi input port? > > If the LS jackmidi buffer size is taken from jack, we've tested this > at 256, 512, and 1024, and got the same result each time, so we're > assuming that jack can handle the throughput ok, and it's not related > to this. (and it's just an assumption at this stage that may, or may > not, be right.) > > Am i asking the right question? > > Any help would be appreciated, as we're working hard to finish this > important feature for our next release. > > > Regards to you all, > > Alex. > > > > p.s. I'm adding the git repo for OOM2 (audio and midi sequencer), if > you want to try this for yourself. > > (user) $ git clone g...@github.com:ccherrett/oom.git > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
