Yo folks! Great to see that there are still people who like to contribute to MusE, welcome, Andrew :)
So let me see whether I can help you: (this is getting a long mail, but i think it's worth reading ;)) first of all, be sure to have a look at muse2/doc/developer_docs.tex and maybe also documentation.tex. Maybe this proves helpful to you; if not, and if you find out how things work, it would be really really great if you improve the documentation there :) as for synthes, there are three important classes: Synth, that is an abstract base class (in java, one would call it an interface) that, well, is an interface to a software synthesizer plugin. Plugin here really means the .so file or whatever. If you have, let's say, three instances of a plugin called "Guitar Synth", then you have only *one* Synth. But you have three SynthIF instances. Synth can be thought of a "factory". SynthI implements the AudioTrack interface. The SynthI::getData() method is the point where the audio thread gets the audio data from. This one calls SynthIF::getData(), which has to be implemented by each synth plugin. No class is derived from SynthI. VstNativeSynthIF, VstSynthIF, MessSynthIF, DssiSynthIF are derived from SynthIF. So this is the point where you should start for LV2 synth plugins, i guess. Plugin is similarly a "factory" for PluginI. However, Plugin and PluginI are not abstract interface classes, but do actually contain the functionality of the LADSPA plugins. You probably (or maybe not, see below) want to turn them into abstract interfaces, move the LADSPA functionality out to a new class LADSPAPlugin(I), and write your own stuff implementing the base classes PluginI, after its creation in mixer/rack.cpp, is pretty dumb. To make it useful, you must call PluginI::initPluginInstance() (which then calls Plugin::instantiate(), which calls some LADSPA instantiate function) Now the relationship between Plugin* and Synth*: both SynthIF and PluginI inherit from PluginIBase. PluginIBase is a (mostly) abstract interface that is used for operating al the "`knobs and sliders"' on a Plugin OR on a Synth (both have (or may have) parameters that can be changed during playback. This is the point where this happens). So possibly, you don't want to turn Plugin and PluginI into abstract interfaces. Possibly you only rename them and implement LV2Plugin, LV2PluginI classes analogous to Plugin(I)... I dunno. And yeah, plugins are not synths, in terms of MusE. Plugins are things that can be put into the effects rack, while synths can not. Plugins cannot accept MIDI data, synthes do. So what you think is correct, *plugins* are populated with libs that are not synth and vice versa for *synthis*. I hope this helps, and I'm really looking forward to LV2 support in MusE. Let us know if you have further questions, we're always happy to help. Cheers, Florian Am 10.09.2014 14:35, schrieb Andrew Deryabin: > 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 > > > > > > > ------------------------------------------------------------------------------ > 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 >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
