> I think it's better to adjust the instrument editor API on sampler side > appropriately.
Hmm, ok, then. To be honest, the only ugly thing about having a 'sentinel' InstrumentEditor is the possibility of never using the SamplerChannel created to get it, but I can work around that by eventually passing the sentinel role to a second set of InstrumentEditor/SamplerChannel if the user starts his session from another instrument than the first one. The important thing for me is that you confirm that keeping an InstrumentEditor permanently open is a viable way of having the gig::File structure locked (or borrowed, to use LS terminology) in RAM so I can change it via the InstrumentEditor API and then call gig::File::Save on it and that there are no obvious easy alternatives that I might have missed. In that case, at least for my sake, I wouldn't put a high priority on the changes you propose, there are probably more important areas of LS to focus on, and I can proceed as I first planned. Cheers, L ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
