Hi! I have been investigating how to convert qgiged into an InstrumentEditor.
The problem I see with the API right now is that IE is very limited in its functionality, probably as a consequence of its delicate interaction with the sampler process. However these limitations get in the way of a comfortable and sophisticated user experience. I'll give an exampler. As things stand now, if you open a gigedit plugin from qsampler and, without closing it, load another instrument in the sampler strip the editor status becomes inconsistent. This is because IE class is too encapsulated and there is no communication path with the main application. There are 4 main actors here: 1) The sampler. 2) The GUI controlling the sampler (qsampler.) 3) The editor object, arbitrating the access to the instrument loaded in the sampler at the time of its creation. 4) The GUI controlling the editor. 1 & 2 are tightly coupled, same as 3 & 4. The problem lies in the interaction between both groups. One could design some external mechanism to connect 2 and 4 (OSC, dbus...) but the identification and registration of newly spawned plugins with the sampler GUI would be complicated. There is also the fact that the editor GUI creation, which is a heavy task, must be done by the editor object. It would be much more convenient if different editors could reuse a GUI by rerouting signals between them than have every editor spawn its own GUI. Now my knowledge of multitask programming is rather basic, so the complexities of it escape me without further research, but I'd like to propose a couple of ideas to discuss with the more knowledgeable members of the project. 1) For applications using liblinuxsampler extend LinuxSampler::InstrumentManager with something like ConnectInstrumentToEditor(instrument_id_t, *InstrumentEditor). That way an application can create and control its own IE and use it to access the instrument memory structure. This is, of course, disregarding LSCP. 2) A more LSCP-friendly solution would be LSCP returning some kind of uid or handle on the editor and a mechanism to pass messages to it. Comments, thougths? Luis ------------------------------------------------------------------------------ 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
