On September 10, 2014 12:35:56 PM Andrew Deryabin wrote: > Hello, All! > > I like muse because it's (as I think) the first complete music > studio for linux with mostly all needed functions on board. > > But missing lv2 support forces me use external plugin hosts such as > carla to make lv2 synths and plugins available in muse. It's not so hard > but rather complex and requires additional steps to set the studio up > and maintain it. > > So I want to implement lv2 host (for synths and plugins) in muse :) > I've already dived into git source for muse project and it looks > rather clear, but stiil I wanted to receive quick info about plugin and > synth subsystems in muse. There are 2 global vars: > *std::vector<MusECore::Synth*> synthis* and *MusECore::PluginList > plugins*. How they are related? (some init code dups for each var). > *plugins* are populated with libs that are not synth and vice versa for > *synthis*? > > > Thanks > Andrew ... of the chunk patches? Welcome.
Two aspects to adding any plugin system to MusE: Effects and synths. Identical in almost every way except that synths accept MIDI, effects don't. Effects are thus available in the effects rack of each audio track, while synths are available as actual MusE Synth tracks. Most plugin systems support some way of distinguishing synths from effects, so we use that to, as you probably saw, marshall them at discovery time into the appropriate global list - synthis or (the somewhat wrongly named) plugins (it holds effects only!). (I think I may have bent that split rule slightly to allow certain plugins to qualify as both plugins and synths. Maybe not, I'd have to check the code where we check the plugin flags and do the marshalling. Anyway be aware of that idea of duality for certain plugins.) One problem with adding more plugin systems is that it's very copious. The code in several plugin.cpp functions is nearly duplicated for each of the plugin systems, as well the the corresponding derivative Synth classes such as found in dssihost.cpp and vst_native.cpp are also copious. I said about a year ago that this was one of the reasons I didn't finish Native VST support (got Synths, need to add Effects!). I wanted to try further fusing/streamlining the plugin/synth system because I also said I wanted to try built-in Win VST support (long been disabled/dead in MusE), so that's Yet Another Plugin System that would need to be supported. It's just my own goal, but look at it this way: do prepare for the future: That's LADSPA, DSSI, DSSI-VST, NATIVE-VST, WIN-VST, LV2 and ... ? Bottom line is go ahead and experiment :-) Add your code to plugin.cpp/.h, and add a new a module (lv2.cpp, lv2.h). Start with plugin discovery sections and go from there. Please do look at the three existing supported systems in those files, and you'll pretty much see and learn it all. I mentioned there's even an old disabled win-vst module which I do try to maintain whenever I change MusE ! Later, we can figure out how to merge it all, it's probably more important at the moment to just get LV2 working! Like, get that code in there... After all, three technologies are already *proven* in MusE. I looked at LV2 before. Off the top of my head, one of the first specific MusE coding problems is that for all three systems we support, we use LADSPA_PortRangeHint to describe ranges and hints. (See the classes, for example in dssihost.h). We need to make a more generalized structure common to all our code - unless... we somehow want, or need, our LV2 code to contain ladspa code. If I recall, once we have done that, there are hopefully no more barriers to merging some of the plugin and synth code, and allowing us to polymorph a couple of classes (I think that's the term - where one class derives from two or more) or make a new class common to both class Plugin and class Synth. Hope that's right. Thanks. Tim. ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
