On Tue, 2004-01-13 at 11:09, Juhana Sadeharju wrote: > Hello. > > I feel we should write a modular synth editor from scratch. > I have checked many existing systems but none is good enough. > > The editor would just be the editor. There would not be > anything related to audio processing. Developers could use > the editor in any project, audio or not. > > The editor would handle GUIs such as in > AlsaModularSynth, > Arts, > Galan, > Gdam, > Glame, > NMEdit, > PD, > Quasimodo, > SpiralSynthModular. > > Also we should have an API and a script in the system. > > I can set up a project folder to our ftp site, ftp.funet.fi, > for resources (manuals and screenshots of existing systems, research > papers). Coding should happen in some CVS site. > > Any comments? > > Regards, > Juhana
(Ironically I've been thinking about this all day during class...) I can't really tell if you're talking about a modular softsynth (ala ssm and ams) or an editor for hard synths (Nord modular?), but I definately think something needs to be done on the "virtual modular (soft) synth" front. (So I'll just go off on a tangent here) The way I see it, the existing efforts all fail in one major way: LADSPA utilisation (well, ssm is getting better here but the polyphony thing ruins it's potential). We have this nice plugin API and _TONS_ of plugins that use it, I think we need (I /know/ I need anyway ;) ) a SIMPLE modular synth app that uses LADSPA plugins (almost) exclusively. Why have yet another app-specific plugin format? Stupid, stupid. That's what LADSPA is for. A nice side effect of this app's existance would be way more nice LADSPA plugins for us all to play with how we choose. The fact that the existing modular synths have their own oscillators (and scores of other plugins) in their own formats seems pretty stupid to me. 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). (If you think this is just a stupid idea you should probably stop reading now...) Criteria I think is important (I actually do use ssm/ams/etc to create sounds for my music and just to fiddle w/ my keyboard controller (Roland A-37), so I suppose I count as a "user" this time..): -- Seperation of UI and backend I don't think the advantages of this need much explanation. Point being widget set wars should be avoided. :) But the engine being seperate definately makes it more useful. -- Polyphony SSM is damn near useless because of this (for me anyway). A monophonic synth is just not a really useful tool when you consider playing it with a keyboard. Not being able to play chords? No thanks. Polyphony needs to be changable on the fly too (ams is really annoying in this regard). -- Subpatches Things get complicated. Abstraction is good. Pd is the only environment of the popular Linux ones that does this AFAIK. Plus, subpatches mean a community can be built up and people can share their "modules" with others to incorporate into their own creations, etc. -- Simplicity Jack in, jack out, LADSPA plugins for pretty juch everything, that's it. Just a simple audio framework and (seperate) GUI to create modular synths. Think 'Unix Philosophy' - once again a good thing that needs no explanation. The only cases where this "everything is a LADSPA plugin" might not be okay that I can think of is PCM in/out and MIDI in/out. Would it be possible to create LADSPA plugins to do this (basically a LADSPA plugin that's an aseq client).. would it be wise? Needs to be sorted out.. I have mapped out pretty well in my head how to make LADSPA plugins completely easy to use in this sort of scenario (from a UI standpoint that is), but I'll spare that for later, assuming anyone cares. -- MIDI control No brainer. Every parameter controllable via MIDI. Similar to ams which is really cool in this department. -- Flexibility This one's a bit abstract I suppose, but every single arrangement of modules, setting combination, configuration, etc. etc. should be possible where feasible. Anyone who likes fiddling with modular synths knows that's pretty much the whole point. This is probably more of a plugin design decision though (ports, ports, ports), with the app being so simple. .... aaaaand I'm spent. Anybody with more ideas/criteria for the perfect modular synth? 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.. (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 ;) ) Discuss.. -Dave
