[linux-audio-user] Your synth wishlist?
drobilla at connect.carleton.ca
Fri Jul 30 13:27:16 EDT 2004
On Fri, 2004-07-30 at 05:09, Thorsten Wilms wrote:
> On Thu, Jul 29, 2004 at 06:26:45PM -0400, Dave Robillard wrote:
> > So, what features are important to you in a synth? What annoys you
> > about the current crop of linux synths?
> I only took a rather brief look at AMS, Galan and SCM some time ago.
> Besides some gui issues the biggest problem was understanding
> how to work with MIDI.
> It would be nice to allow MIDI to be used like this:
> - start with a input module
> - filter out a channel
> - optionaly filter a range of notes
> - send the signal to an osc
> - the osc automaticaly plays the right frequencies
> - the full midi signal is put through to the output
> - a following envelope can be triggered on note-ons,
> a filter can have its frequency modulated by the velocity,
> all without extra cabling
This would be pretty cool, but unfortunately this engine knows nothing
of MIDI whatsoever, it communicates via Open Sound Control. The idea is
to keep it as generic as possible.
The problem with what you want (having "midi cables" in a modular synth)
is we don't have a plugin format that supports MIDI yet. Like
everything else, we just have to wait on GMPI for this. :(
It is possible to send MIDI via OSC, and I would consider implementing
what you said if we had a plugin format that allowed it. Unfortunately,
If it helps, you can algorithmically play with MIDI like this using Pd
if you're up to it.
> Sending 2 or more outputs to 1 input could lead to
> automatic creation of a mixer module.
That would be nice. On the list.
> modules I would like to see:
> - a sample player with variable speed, direction, pitch,
> - a buffer that can be used to cut of a variable part of
> the begining of any audio signal
> - a mapping module with x and y axis and a curve like known
> from Photoshop or the GIMP
See my other post about LADSPA and plugin formats etc. We all want
> I would like to see a system of assemblies/sub-assemblies
> and patches.
> The full setup of modules and connections would be the
> assembly (just using this term because I have the idea from
> Solidworks). Now an assembly can contain any numbers of
> assemblies (making them sub-assemblies). But they all are
> stored in seperate files.
> Patches would work on top of assemblies, by bringing in
> the specific settings of all parameters (a patch for the
> top assembly could reference patches for all contained
I don't think the distinction between "assembly" and "patch" is really
necessary, sounds like the same thing to me. Basically, you want
subpatches (within subpatches within subpatches).
I agree.. I'm not sure if it will be implemented in the engine or front
end (which is a more LAD appropriate discussion, you guys don't care as
long as it works, right? :) ), but subpatch ability is crucial. On the
list (pretty far down though, I must admit)
(Thanks for that, by the way, I totally forgot about subpatches)
> To make it all perfect there should be a versioning system,
> but I guess that's a bit much to ask for :)
Versioning as in CVS for patch files? Well.. yeah, that is a bit much
to ask for. :)
Put your patches in a CVS repository. Done. (They will be xml and CVS
will handle it nicely). CVS is actually a lot simpler to use than many
people give it credit for, for simple things like this anyway.
> An old idea for a modular synth gui:
> make it zoomable! Zoomed out you would have a nice overview
> even of large systems. Zooming in allows to easily manipulate
> controls right on the modules.
That is a good idea. Once I get around to the GUI, I'll consider it.
It actually shouldn't be that difficult if it's planned ahead of time.
Once again, good idea to bring up, thanks.
> A variation on this would be a fish-eye like effect, showing
> the area around the pointer large, with decreasing size
> with growing distance from it. Of course without distortion,
> but working block by block.
Heck, go big or go home! OpenGL accelerated GUI with fisheye lens
.. or not. :) Fisheye would be feasible, but having controls show up on
the modules and actually being able to play with them would be tough.
Personally I think just plain old zooming would be adequate, if it's
done in such a way that you don't "lose your spot" when you zoom back
out. Holding a mod key and moving the mouse up/down seems like the best
idea to me.
> There are some small ideas from my work on Specimen that
> might be interesting for single modules. But for now
> it should be about the big picture, right?
Once again, the Plugin Format Problem(TM). But on the topic of
specimen, how difficult is it to write alternate frontends for specimen?
I'd like a drum-based sampler frontend like Hydrogen's mixer quite a bit
(not a big fan of hydrogen for reasons I won't go in to)
Good ideas, thanks for the input
More information about the Linux-audio-user