> 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? >
Then it is I who is missing something, which is not strange, please bear with my limited understanding. Correct me if I am wrong. As I see it, the way to spawn an editor from an app is: - Create a plugin dll and install it at the plugin dir in place of gigedit, since only one single editor is supported. - In the main application: - Create a Sampler object. - Add a SamplerChannel. - From the SamplerChannel get its EngineChannel. - Use the EngineChannel to load an instrument. - From the EngineChannel get its engine. - From the Engine get the InstrumentManager. - Use the InstrumentManager to launch the InstrumentEditor. If I follow this path I don't get any reference to the InstrumentEditor which is created by the sampler, so I don't have any direct means of communicating with it from my main application. I haven't got around to implement this yet, but I am all ears about any other approach that allows me to get direct control of the editor, I have only scratched the surface of LS API and I may be missing some key pieces here. > Like e.g. extending LSCP for instrument editing? If yes, I'm not convinved of I was thinking of just a generic transparent message passing mechanism, like OSC. It would be up to the application programmer to determine the semantics of the protocol to control the editor. This would be simple to design and implement and unspecific enough, wouldn't it? Yet it would provide a valuable tool that now doesn't exist. Then again, it may exist and it is not apparent to my eyes. > 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. Please bear with me, I am not criticizing LS design principles. My apologies if it sounded like it, it was not my intention. I am just trying to contribute a new piece to the puzzle and looking for the best way to do it. My approach is 50/50 musician/developer, so my coding-fu is necessarily limited. I have followed the project a long time and I remember how the editor API was discussed, conceived and slowly improved. So far I had the impression that it had not been pushed too far. It is clear that gigedit contributors have only so much time to invest on it and it has not had the time to mature yet to a more featured tool. I am well aware of the usual limitations of free projects and I am not proposing any big changes like adding GUI toolkits (where did that come from?) of a full language of remote instrument edition. I just want a tiny hole in the wall from where to see my editor from my main application, I'll take care of the rest. Perhaps it exists already and I just haven't found it yet. 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
