On Wed, Aug 08, 2012 at 09:28:39AM +1200, Jeff McClintock wrote: > I think I good experiment is to imagine you have to write both an LV2 host > and 100 LV2 plugins, and you have to write MIDI-binding code. Do you put it > in the plugin OR the host? > -If a feature consumes 100 kB RAM and disk space, and it's implemented on > the host side - that's 100 kB. > -If it's implemented on the plugins side, that's 100,000 kB. > > Which choice is more 'bloated'?
If the MIDI-binding code is in a shared library (and it probably should be) then there's little difference between these two. Code is shared. Per-instance data isn't, in the first case the host would allocate it if it loads a plugin and in the second case the plugin would do it, but again the total size would be the same. > A very real scenario is you write this MIDI-binding support, ship 50 > plugins, then 6 months later discover a bug. Now if that feature is in the > host - that's one fix and everyone is happy. If that bug is in the 50 > plugins, already shipped to 1000 customers. Then you have a much bigger > problem. Again if the code is an a shared library that is the only thing that will need to be updated. > It's not a question of 'bloat' YES/NO. The code has to go *somewhere*, there > is only a tradeoff - HOST vs PLUGIN. Yes, and the choice should IMHO be made based on *operational* requirements. Does a MIDI controller control 1. a GUI element (e.g. a fader) which in turn controls a parameter, or 2. does it control the parameter, updating the GUI as a side effect. In case (1) the midi controller can use the mapping (e.g. linear or logarithmic) of the GUI element, which may be a desirable feature. Also imagine that the plugin GUI and DSP code (and host) run on separate machines. For example the host is some complex rendering engine placed in a technical room while the plugin GUI runs on your on-stage laptop. To which one would you want the MIDI controller connected ? Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
