On 09/04/2009 11:29 PM, Gabriel M. Beddingfield wrote: > > On Fri, 4 Sep 2009, Patrick Shirkey wrote: > > >>> If we spin off libhydrogen, we could: >>> >>> * Offer Hydrogen sampler as a plugin. >>> >> Where's the interface? >> > Do you mean GUI? It depends on the plugin system... but generally plugins > don't come with GUI's. There have been several requests to have Hydrogen > as a DSSI or LV2 plugin. > >
Are those requests specifically for ui less plugins or do they just want ot be able to run the hydrogen interface as a plugin? >> Couldn't we just make the existing system more flexible by providing a >> class that manages the various interface requirements? >> > H2Core::Hydrogen is a singleton class, as are many other critical classes. > This means that there can only be _one_ instance in the application. To > get more instances, they have to be in different _processes_ (as opposed > to threads or whatnot). Even then, they are programmed in such a way that > it's clear "There is only one" (config files, autosave, etc.) > > This makes it hard to re-use Hydrogen as something like a plugin. Even if > you load the "Hydrogen Synth" plugin twice... I'm pretty sure there will > only be _One_ hydrogen, _One_ song, _One_ drumkit. > This could be solved by having a more flexible xml syntax taking into account the possibility of multiple instances. But what is the liklihood of anyone wanting to run more than one instance of hydrogen at the same time? > ...but I'm talking out of my league on this one. I've never written a > plugin. > > I assisted with the development of one ladspa plugin so I'm not a plugin expert either. >>> * Offer the 'classic' Hydrogen front-end, and possibly >>> spin off a new application with the Live-like >>> front-end. Both would use the same back-end. >>> >> One interface for this which takes a runtime flag to define the layout >> would achieve the same goal. >> > This sounds (to me) like a disaster and a maintenence headache. The different layouts would still be modular so the basic principals would apply. I guess it's a case of having one app or mutilple apps. > Why not > just fork the front-ends? That's essentially what you're doing with the > command-line switch. > That's true but not forking would allow for runtime switching between interface layouts which is kind of cool too. > One way I was thinking we could divide things up is to possibly call the > library (or the new front end) "Tritium" -- i.e. radioactive hydrogen. > Cool name. > As long as the library provides a consistent API... the maintainers of the > two front-ends would be able to chase their different goals without > stepping on each other. > > This would apply equally for both options if the hydrogen lib code was fully separated from the interface. In both cases UI dev and backend dev shouldn't clash and if they do that would need to be addressed first. However providing a sepearate library would also allow other projects to start integrating with the lib. >>> * something else... >>> >>> >>> >> Phew, I'm a sucker for hard work but not sure if I can accomplish this >> one.... ;-) >> > Ha! Well, the concept is very unix-ey. While we're talking about a > monolithic front-end, the back end components would be modular in > nature... allowing them to be reassembled by other applications to do > things that we never dreamed of doing. > > Allowing other apps to reassemble the hydrogen core is a mighty goal but maybe not an immediate priority. I agree that keeping the backend as modular as possible is the right idea. I think that splitting off the core libs would be useful but access to the backend for many uses could also be provided by a runtime switch or daemon mode. I guess that is the major decision to be addressed. Perhaps both angles can be developed in tandem as there is a huge amount of crossover. For example after working on getting the interface completely seperated so that it can be switched on the fly to live and standard mode that would make it a lot easier to build split of the libs. But it's kind of a 6 of one and half the other situation. With the latter we get to have a live interface to play with and test with prior to libifying but it could become a distraction... Cheers. Patrick Shirkey Boost Hardware Ltd ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hydrogen-devel mailing list Hydrogen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
