From: Vesa <di...@nb...> - 2014-05-30 16:01:26
|
On 05/30/2014 06:34 PM, Tres Finocchiaro wrote: > > ... could we create a gui within lmms that taps into those features > and wont require coding > > Are you trying to describe a plugin builder? > > It would be quite cool to take a QML-like approach and have IDE-style > drag-and-drop plugin building using existing components but as a rule > of thumb, whenever end-user software tries to code itself, it is > usually a bad idea. The reason the dev team would spend the next 6 > months creating an interface for creation and unless users are > screaming at us to make their own 1-off instruments or plugins (which > they aren't, they're still learning the ones we have) I don't think > there's a demand for such feature. Well, I've actually thought about this before. The way I see it, if we wanted to implement our own modular synth, it could be done. It'd be entirely possible with the building blocks we already have. Qt provides us with XML for saving the information about the modules and connections, we could have a set max amount of user-definable controls ( kind of like Vestige has a number of controls that get defined by the plugin )... > > Worse, each component would have to be rewritten for modularization. > What you are describing is a mess, IMO. Actually, this isn't necessarily true. Most of the internal DSP code that we have is already very much modular. It's just the higher level user-facing features of LMMS that are more linear, the UI and the instrument -> fx chain -> mixer paradigm ( and even our mixer is now modular, at least internally )... the actual lower-level DSP components - filters, effects, generators, etc. - are already modular and can be used very flexibly. The entire modular synth could be written as a native LMMS instrument plugin. This is entirely possible with the components we have now, it would certainly be a lot of work, but it is possible to do. I've played with the idea of a true modular synth that uses native LMMS components to implement the modules. It would be very simple in design, containing three types of user-definable elements: controls, modules and wires. Controls would work as such: each can be either a knob, a toggle-led or a combo-box with defined options. Writing the XML and other structures for this shouldn't be too hard, we have something very similar in the Ladspa hosting code already, and we could just adapt that for this purpose. Modules could be basically just functions inside the instrument plugin, which get called per period. For example, the XML of the modular-synth-preset could state that there are 3 oscillator modules, and then each period, the modular synth would call the oscillator-function three times, and tell them to write their output to the wires they're connected to. Wires would basically be buffers that connect modules to each other. When the modular-synth-instrument-plugin calls each module's associated function, the function writes its output to the wire buffer, and then the module at the other end of the wire can read its input from the wire and output to another wire... Writing the actual synth would probably almost be the easiest part of this. The most difficult part IMO would probably be in implementing the editor for the modular synth. It'd require lots of UI coding, new custom widgets, etc. We'd have to decide whether the editor would be a part of the instrument plugin and thus work inside LMMS only, or if it should be an external program, either option has its pros and cons, both have different challenges... In conclusion, I think a native modular synth for LMMS would be entirely doable with our current assets, but it would be a very huge amount of work to do, and since we have plenty of stuff to do already, I'm not sure if we should put our limited resources towards it... at least not at this point in time. Another option to consider is to use an existing, mature, maintained-by-someone-else solution, such as AMS or Ingen, and integrate it with LMMS. That'd probably be a lot less work for us, although it would allow us much less control and less features - it'd probably have to be a midi-based single-stream instrument, and thus would have less functionality than a native solution in some aspects (no per-note pitch, no env/lfo...). |