On Wed, Jun 16, 2010 at 1:38 PM, alex stone <compos...@gmail.com> wrote: > On Wed, Jun 16, 2010 at 1:09 PM, Christian Schoenebeck > <schoeneb...@software-engineering.org> wrote: >> On Tuesday 15 June 2010 18:03:25 Christian Schoenebeck wrote: >>> > I get the impression this is about "live" loading and unloading, where >>> > a sequencer reads ahead, and at a given point, swaps one gig for >>> > another. (Sort of like, "in 5 bars time i need 1st violins staccato, >>> > so i'm going to load it in the background 4 bars before it's needed, >>> > and dump the existing 1st violins legato just after the staccato >>> > starts.) >>> > >>> > If this is the case being described, then i would think it's the >>> > sequencer's responsibility to provide read ahead functions, but some >>> > mechanism that tells LS to load another gig in the background, and on >>> > receiving a message from the sequencer, dumps the existing loaded gig. >>> > >>> > I guess you could say this might be" >>> > ON_DEMAND_UNTIL_MESSAGE_RECEIVED_TO_DUMP_CURRENTLY_LOADED_GIG". >>> >>> Well, we could either introduce something like a MIDI SysEx message which >>> could trigger unloading one instrument or we could change the >>> implementation of the program change message, in that way that it would >>> simply unload the current instrument in case a bank / program number was >>> selected which is not defined in the MIDI instrument map of the user. >>> >>> At the moment the sampler simply ignores such invalid bank / program change >>> commands and leaves the current instrument untouched on that sampler >>> channel. >> >> Ah, as a simple workaround you could do it like this: create a dummy .gig >> instrument with gigedit that has no sample at all and map that actually >> useless empty instrument in your map. Then you can load your actual >> instruments on demand on the respective channels and when doing a program >> change to that empty instrument, it will free the memory. >> >> CU >> Christian >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Linuxsampler-devel mailing list >> Linuxsampler-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >> > > Hehe, this is all the more clever for its simplicity. Sometimes us > users stand too close to the trees. > > Thanks, great tip for at least part of this challenge, i'll try this. > > Alex. > > -- > www.openoctave.org > > midi-subscr...@openoctave.org > development-subscr...@openoctave.org >
As a follow up, this would be ideal for sequencers that either have single channel per track (1st violins track1 up bow channel 1, 1st violins track2 down bow dual channel 2, etc) or sequencers that have 16 midi channels per track, and the user can send individual bank/patch messages per channel. (which we don't have in linux audio just yet.) So in the case of openoctave midi, we could have something like 4 1st violin channels, and send the "blank" gig bank/patch after each patch we're using is finished with for the time being. The loading time for gig files ON_DEMAND is still a factor, but as a workaround, we can load the same gig in a different track in advance, calculating the time it takes to load which ever gig we want. (On average my strings take about 3 seconds to lad, and the oboe and french horns take closer to 10. This varies of course dependent on the sample libs being used.) A bit more management involved, and a slower workflow spacing gig bank/patches, and calculated load times across multiple tracks, but it's at least a partial solution to running out of mem, which is a non result in any use case. So in the case of ON_DEMAND_HOLD, sometimes required for rapid changes between patches, we expect the "blank" gig to unload the current ON_DEMAND_HOLD gig file in the specified channel, yes? Alex. -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
