New subject: [ken@restivo.org: Re: [LAD] Descent synth as dssi]

9 Mar 2010

On Tue, Mar 09, 2010 at 07:04:26PM +0100, Burkhard W??lfel wrote:
...

 Am 06.03.2010 um 07:19 schrieb Ken Restivo &lt;ken(a)restivo.org&gt;rg>:

  On Fri, Mar 05, 2010 at 10:16:51AM -0600, Josh
Lawrence wrote:
  On Fri, Mar 5, 2010 at 4:43 AM, Gerald Mwangi
&lt;gerald.mwangi(a)gmx.de&gt; 
 wrote:
  Hi, does anyone know a synth powerfull like
zynadd, phasex or
 bristol,but in dssi format? I need something I can load into  
 Rosegarden,
 since I dont want 10 Standalones running, until ardour, rg and the
 synths support LASH, if that ever happens. 
 I have no idea why, but I have a warm, fuzzy soft place in my heart
 for DSSI plugins.  they always seem to just work.  whysynth has
 already been mentioned, but be sure to check out the calf monosynth,
 which can be run as a DSSI plugin:

 jack-dssi-host calf.so:Monosynth

 check out the DSSI home page too, for a lot of other options.

 I'm hoping this thread will reveal some that I don't know about!  we
 really need something like specimen in DSSI format.

  I think LASH should be integrated into Jack, to
make it mandatory  
 for
 linux audio apps. The missing LASH support is one of the main issues
 disturbing me, when working with linux audio. Now I've said it, ha.
 I'm thinking of having Jack require a Load/Save callback, prior to
 activating the client. How feasible is that? 
 why oh why oh why did you throw this paragraph in?  now no one wants
 to talk about DSSI anymore... :(

 +1 for Calf Monosynth and WhySynth. They, in addition to AMS and  
 PHASEX, are the synths I've used most.

 Zyn is kind of old and doesn't do RT; the new thing is Yoshimi, and I 
 dunno if it supports LASH or ladish, but I'd guess both.

 For the record, I *HATE* session management and I don't run LASH at  
 all when I can avoid it (IIRC, there's some synth that I use or used  
 which requires LASH, so I occasionally have to start it up).
 I generally can't stand technologies that try to be "smart" and do  
 things I don't explicitly instruct them to do. Frustrates the hell out 
 of me.

 FWIW, I am also the kind of guy who turns off autocomplete and  
 spelling checkers whenever I can.

 How would you share a complicated production setup, aka session, with  
 other users? Script, or text explanation? Screenshot? Ardour audio  
 project only?

 I'd love to have a rather bullet proof way to make my sessions available 
 to non-geek collaborators really fast and easy. And vice versa.

 Software trying to outsmart the user can be painful. On the other hand, 
 there are users out there waiting to hop on the linux audio boat as soon 
 as there is an obvious way to save and restore complex setups without 
 scripting. I'd love to make music with them.

 It's good that you are happy with your way of using your DAW and so am  
 I. But it makes me a little sad sometimes that for remote collaborators 
 the learning curve is so steep.

My setup is not designed for remote collaboration.

However, the Packet-In project (http://packet-in.org) found a reasonably workable process
for doing remote collaboration. It's been a few years, but IIRC it involved
FTP'ing ogg files around.

Also, there are collaboration websites that offer a lot of that infrastructure in a
convenient and slick interface-- doesn't matter what DAW or synths or tools each
participant uses. You could be collaborating with people using Logic or ProTools or
Ableton or just a random collection of command-line synths like I use-- and it all works
smoothly. I don't remember the name of the site, but Drew pointed me to one last year,
and I found it a really a cool collaboration tool, kind of like GitHub for music.

So, for remote collab, I think the most portable and flexible solution would be to move a
lot of the collaboration functionality out of the DAW or synths, and out into the Web 2.0
cloud instead. Then it becomes DAW-agnostic.

And yes, the average non-techie user wants a monolithic app that just saves/restores and
gives them an all-in-one user experience. I prefer working in a more unix-y way: small
daemons and tools glued together with scripts. But that's just my personal workflow.

-ken