The only thing that struck me is that I'm under the impression that memory allocation and deallocation, even by the GUI thread, can cause pauses to the whole process. Hence, a threading model is not enough for decoupling memory allocation pauses. Can anyone comment on whether this is true? My impression is that at least a new or malloc can stimulate a brk()/sbrk(), which will generate a page fault. Not sure about deallocations.
Of course, a pre-allocated object pool can deal with this. Steve On Sat, Aug 6, 2011 at 5:57 AM, Florian Paul Schmidt <[email protected]> wrote: > On 08/06/2011 04:23 AM, Florian Paul Schmidt wrote: >> >> Hi, >> >> during the process of writing a new small jack sampler which fits my >> workflow I came up with this little scheme to solve the UI/engine decoupling >> problem. For the purpose of spreading the idea or alternatively getting >> answers about how it's broken and sucks I decided to write a little article >> describing it.. >> >> http://178.63.2.231/~tapas/wordpress/?page_id=45 >> >> The (largely unfinished and unusable) sampler project is here: >> >> https://github.com/fps/jass >> >> Let me have it.. > > I guess I should mention the approach in a nutshell. Assiging a new > generator (that plays a sample) to the first element of a std::vector of > generators in the engine the UI would do e.g.: > > engine.commands.write(assign(engine.gens->t[0], p)); > > where assign() is a function that builds a functor that dassigns the right > argument to the left, p is a > > boost::shared_ptr<disposable<generator> > > > or with typedef > > disposable_generator_ptr, > > gens is a > > boost::shared_ptr<disposable<std::vector<boost::shared_ptr<generator> > > > > > or with typedefs: > > boost::shared_ptr<disposable<std::vector<disposable_generator_ptr> > > > or even shorter > > disposable_generator_vector_ptr > > Replacing the whole vector of generators with a new one (after e.g. loading > a complete setup) wood look like: > > engine.commands.write(assign(engine.gens, v); > > where v would be a disposable_generator_vector_ptr. > > Just calling the set_sample member of a generator would look like this: > > engine.commands.write(&generator::set_sample, engine.gens->t[0]->t, s) > > where s is a disposable_sample_ptr.. > > The ->t thingies show up, because every object is wrapped in a disposable<T> > which has a member t that is the "payload".. > > I wonder if there's an even more elegant approach to cook down the verbosity > a bit.. What you get, though, for the verbosity is the ability to call > almost every member of every object in the engine's collection of objects > without writing extra classes to define a command.. Such is the power of > boost::bind and boost::function.. > > Flo > > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
