> I think the main reason for this (for SSM at least) is firstly that LADSPA > support came after the app was developed, and secondly LADPSA plugins don't > have GUIs - these have to be generated, with limited success. SSM is great in > this regard - the native plugins all have really cool GUIs.
Rather than having GUIs to control plugins, I was thinking ports would be used for the most part.. real analog modulars don't have nifty GUIs :). The GUI problem can be solved pretty well with a slightly more advanced version of what SSM is doing (in CVS) right now... I havn't really seen any LADSPA plugins that need more than a bunch of sliders/knobs. The ideas ams/ssm have used are pretty good, but I would add the capability of choosing on an individual control basis whether the control was in the GUI, or exported as a port. This is definately something severely limiting about ams for me right now... (sure, you can use MIDI out to get around it, but ew). > Another issue is that LADSPA plugins cannot be used for sample playback, as > loading samples is impossible unless you stream the data in a la SooperLooper > (http://essej.net/sooperlooper). This is where the simplicity comes in.. we're not making a sampler :). Use an external sampler, if you want the audio in the synth, bring it in as audio. I really think the modularity of the, *ahem* "Linux Audio Architechture" should be exploited fully. Something like: Keyboard --(MIDI)--> Sampler --(JACK)--> Synth --(Jack)--> Output And you could also of course run the midi into the synth as well to mix sampled and synth sounds in any way you choose. A dedicated sampler prog is going to be a heck of alot better sampler than some little plugin in a modular synth, might as well utilize it. (Plus you could use drum machines like hydrogen, or whatever you please as an audio source.. including real-time live audio from a mic or instrument..) > > I don't think an app like this need be that complicated: all it really > > needs to do (in the audio engine) is allow connecting LADSPA plugin > > "ports" to other plugins. LADSPA being what it is; that's not such a > > difficult task (and most of the code could be borrowed from existing > > projects anyway). > > Agreed - at the lowest level it's a directed graph traversed in topological > order - a solved problem. The complicated bit is the interface and additional > functionality (subpatches etc), which is what differentiates existing synths. Subpatches and good polyphony will be the complicated parts, I don't think the UI will be that tough actually. > > (If you think this is just a stupid idea you should probably stop > > reading now...) > > Not at all. It's a great idea. > > > [...] > > Anybody with more ideas/criteria for the > > perfect modular synth? > > OK here I go: From my notes (and fuzzy memory :), what I'd like is a simple cli > program that communicates via some form of IPC. OpenSoundControl (OSC) would > seem to be a good mechanism, as it's quite widely supported and should be > sufficient for all that would be required. > [chop] Making an "interface" or communication protocol, IPC, whatever you wanna say I think is way way way overshooting what needs to be done. What's the point really? The overhead is definately not worth it (realtime audio..). The engine should be just code, straight up. We need to design the architechture of the _program_ not an interface. If you really wanted a UI like what you described, it could be implemented as, well, a UI plugin. This is my idea anyway, if you have some good rationale for a system like that please elaborate, but I think you're overthinking. I know, I'm really clinging to simplicity here, but it's for good reasons: simplicity breeds usefulness (UNIX), but more importantly, simple means the damn thing will actually get _written_ :). > I agree with your points, besides the Audio + MIDI I/O - I feel these would be > better implemented as non-plugins. There's also the sample load / save / > playback issue to consider. I agree about the IO, it would probably be better to have those as special things (but they'll still just appear as plugins with ports to the user of course). See my note above about sampling, out of the domain of this project. > > For the record, absolutely no disrespect towards authors of existing > > efforts (ams, ssm, both great and certainly have their plusses), I > > probably wouldn't have known what a modular synth was if it wasn't for > > you guys ;). Gratitude.. > > Indeed. There's a lot of good ideas in all these apps - it's worth considering > whether efforts could be directed to improving these, rather than starting > totally from scratch. However, this is likely to be more difficult! Absoluteley. Probably AMS because ssm is just not as solid (sorry!) and the polyphony issue.. > > (Also, yes, I'm actually a coder, and yes, I'm willing to take this on > > (time being limited as it may be).. I'm not one of those self-appointed > > open-source-developer-dictators ;) ) > > I'm willing to help as well - I've been slacking off on this issue for too > long... Well, if it is decided some hardcore hacking on an existing project is needed, at least we've got two. Is the interest in modular synths lower around here than I would have expected? (Roll call) > - > Myk > > > ________________________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html
