On Tue, Mar 09, 2010 at 07:04:26PM +0100, Burkhard W??lfel wrote: > > > Am 06.03.2010 um 07:19 schrieb Ken Restivo <ken@xxxxxxxxxxx>: > >> On Fri, Mar 05, 2010 at 10:16:51AM -0600, Josh Lawrence wrote: >>> On Fri, Mar 5, 2010 at 4:43 AM, Gerald Mwangi <gerald.mwangi@xxxxxx> >>> 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
