Es geschah am Monday 16 March 2009 als Luis Garrido schrieb: > > The only inconsistency that currently exisists in this case is that the > > virtual keyboard of the instrument editor still sends note on/off events > > to > > Yup, that's what I meant. > > > Why would you want to connect the sampler frontend application and the > > editor GUI? What are the events you have in mind which should be sent > > between the frontend applications and the instrument editors? > > To integrate both in the same window. My plans are to add a sampler > strip to qgiged so you can load an instrument to it from the gig > explorer widget. I want to have one "active" instrument who "owns" the > part of the GUI dedicated to instrument edition. This instrument may > or may not be loaded in the sampler at the moment of edition.
But in this case the channel strip and editor are part of the same application, so you can do your communication between them internally as you like, without having something to modify about the liblinuxsampler API. Or what am I missing? > > You mean for allowing a frontend application to assign another instrument > > to an already opened instrument editor? > > I mean liberating the plugin of its GUI duties, so you don't have the > "one instrument - one window" model, and let it concentrate on message > relaying. Like e.g. extending LSCP for instrument editing? If yes, I'm not convinved of such an approach. Because it's quite hard or even impossible to define such a protocol without getting format specific. The current InstrumentEditor interface class is format independent. And it takes a long time to define and implement such a command set. The audio / MIDI device management command set of LSCP is a good example: http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#anchor9 http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#anchor10 We designed it driver independent. That is, a frontend can manage all current and future drivers and their parameters without the frontends knowing anything about driver implementations at compile time. Since it requests all informations about those drivers by LSCP at runtime. But it really took a loooong time to implement that correctly. And an instrument editing command set would even be more complex, so even a lot longer to implement. So I *think* our current approach, with a very minimalistic, native instrument editor API is a good compromise between features / power and development speed / progress. CU Christian ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
