On Friday 30 July 2004 04:07 am, Steve Harris wrote: I'm having a look at the RFC... I only know of DSSI because a couple of the MusE guys wanted to integrate it and got shot down. PS to list at large FYI: I'm completely ignorant of the current linux audio scene, but I've been around as a developer on the platform. I have a music/audio background and I'm "getting back to my roots" for the next phase. A few more clue-impaired statements are likely while I'm ramping up. If I say or miss anything that should be "obvious", clue me. I intend to take on some of the documentation issues as part of my larger strategy.

On Thu, 2004-07-29 at 22:03, Russell Hanaghan wrote: [snip] Yeah, that's pretty much a completely different beast. But it would be silly to make a specific module for just one sound set, that's why we have gigasampler, soundfonts, etc. What I think you need is for linuxsampler to become a usable gigasampler player (it kinda works a little bit sometimes right now) - there's some disturbingly nice gigasampler libraries out there. -DR-

On Fri, Jul 30, 2004 at 01:34:05PM EST, Rick Henry wrote: Have you tried running it under Wine? -- Luke Yelavich http://www.audioslack.com luke(a)audioslack.com

i have a few things, besides the easy-midi-map. (reaktor is pretty easy that way i think, like click/highlight a knob or slider and then move any controller to map it, maybe with a modifier key..?) anyway. two things, coming from the world of supercollider objects: one is phase modulation. a typical Sine Oscillator, say, should have at least four inlets: frequency, phase, a multiplier-in and an amplitude-in. two is a buffer reading oscillator. which is to say, a sample player, but one that has controllable playback functiosn, as if it were any old wavetable synth. but that wavetable could be a many minute long sample? -- _________________________________________________________________ Jonathan Segel -- MAGNETIC -- PO Box 460816 S.F. CA. 94146-0816 jsegel(a)magneticmotorworks.com <-----> magsatellite(a)yahoo.com http://www.MagneticMotorworks.com

On Fri, Jul 30, 2004 at 12:50:28PM -0400, Dave Robillard wrote: Yes, DSSI can handle samplers - fluidsynth has been wrapped as a DSSI plugin I think. - Steve

fre 2004-07-30 klockan 20.29 skrev Dave Robillard: If linuxsampler provides the same gui/engine separation as fluidsynth does it wouldn't be difficult to wrap it up with M.E.S.S or DSSI and throw it into MusE or RG, together with a bank of good drumsamples and some preconfigured "drumkits". Not to mention all the other fun things you would be able to do... I don't know much about linuxsampler though, does anyone know how it will work with LADSPA-fx, routing and midi? Will it provide send-fx that could be controlled via midi, for different channels etc etc or? Hmm, better check the archives... /Mathias

fre 2004-07-30 klockan 22.24 skrev Steve Harris: Just had a _very_ short look (and that look looked quite good ;-). I guess it wouldn't be a problem to control it, but to wrap MESS on top, you need to be able to get the audio output (to feed it further into MusE). Perhaps another backend is needed for that. Didn't look that deep though to see how tricky that would be. Ah, well. Not today. /Mathias

On Friday 30 July 2004 05:35 pm, Russell Hanaghan wrote: I would imagine 128 is just a start. You'd need 256 and interpolation to just cover timbre changes relative to dynamics without a filter envelope. Crafting good sample sets is a lot more involved than making digital mellotron tapes.

On Fri, 30 Jul 2004 12:50:28 -0400, Dave Robillard wrote agreed - I'd rather extend LADSPA to allow things like disk access and other non realtime tasks than create a new standard. Is this at all possible? dave

On Friday 30 Jul 2004 5:50 pm, Dave Robillard wrote: I would love a DSSI drum synth. I spent a while badgering Steve to write one -- he admitted to a latent interest -- but he resisted. Chris

On Thu, 2004-07-29 at 15:26, Dave Robillard wrote: Only that the mostly work only as jack clients, not as DSSI/MuseSoftsynth plugins. I can see that a modular synth would be hard to make work in these systems (because ofthe automation complexity), but a frozen version of a particular setup could be made to appear as a muse/ssi synth. I understand that DSSI and Muse softsynth APIs are not widely used (2 DSSI hosts, and 1 Muse that I know of), but more synths would propote more host support. Do you mean working as, or loading? - Steve

I'm going to reply to a few emails in one go here and then drop out of the thread, because I don't think this is on-topic for LAU any more. If you want to reply further it might be worth taking it to LAD (or even the dssi-devel list on SourceForge -- so far unused -- though I don't think that's really the right place for philosophical discussions about the nature of plugins, more just for practical implementation stuff). On Friday 30 Jul 2004 7:22 pm, Dave Robillard wrote: I agree with it in certain instances. I think a synth plugin format is very appropriate for "small" synths, or for synths that (like most VST instruments) are designed to produce a particular recognisable sound. If you have a decent standalone JACK host as well (and the DSSI example host is not quite good enough yet -- it doesn't do a very good job of dejittering the timing of incoming events) then you have all you need to write a simple plugin and have it work all ways. That's the thing I really like -- the possibility of writing it once and using it in many different ways, which using a plugin API permits. I don't however particularly think you should attempt to make a real modular synth into a DSSI plugin. Anything where the GUI is designed to do serious editing work, rather than just tweaking a few values, is IMHO probably not a great fit. Using external soft synths (JACK/ALSA style) for a sequencer like this is at the moment rather hard to do in a user-friendly way, for various reasons (some of which are outlined in the DSSI RFC). It's great to be able to do it at all, but it's better to have a choice. I just don't think that will happen. Even as a developer of one of the other Cubase-alike applications, I think there's just too much flexibility there: the fact that Rosegarden plugs into a JACK graph so you can use and sync it with freqtweak, Ardour, jack-rack, JAMin etc is of huge benefit to users of Rosegarden just as it would be to any other application. This communication ability is an area in which Linux apps are better than Windows ones, and that benefits all kinds of applications equally. Not "all" the synths. But there are definite benefits to users of sequencers of having synths that can plug tightly into them. Yes, I think so, just as you can write LADSPA plugins that load LADSPA plugins. My view is that for writing plugins, there's rather little effort involved (other than the work you'd be doing to write the synth anyway). DSSI hosts are much harder to write, which is the way it should be. I personally have no great interest in waiting for GMPI just so I can have synth plugins in my sequencer, but GMPI should certainly offer some more interesting stuff (e.g. DSSI lacks any way to invoke notes at frequency rather than simple MIDI pitch, etc). Because it originally arose from a desire to use soft synths in plugins, because we wanted to constrain the requirements to things likely to be useful for straightforward synths, and because it was easier to describe and (if you like) sell the idea than if we called it an extension of LADSPA. There's just too much flameage in extensions of LADSPA. DSSI is a take-it-or-leave it thing that just happens to have LADSPA plugin technology in it. No reason. Although actually you could probably also create pure LADSPA plugins and use DSSI-style GUIs with them with a suitably aware host. I _think_ that Rosegarden 0.9.9 will happily start up a DSSI GUI for a LADSPA plugin as well as a DSSI one if it happens to find one -- I haven't tested it, but the code shouldn't care what sort of plugin it is. Chris

On Thu, 29 Jul 2004 23:29:04 -0400, Rob wrote What about clicking a "set midi control" toggle button that puts the synth in a mode where you waggle your midi controller at the same time as the corresponding software slider and they are bound togther. That way you could really quickly set up controls without going into menus etc. Thats what I'm planning for the noiseweapon synth anyway... FWIW this ladspa only softsynth is something I've been itching to do for ages, I think it's a really good idea. Maybe it would require some specialist LADSPA plugins that would be needed for a softsynth, but I think this is where the functionality belongs, rather than in client code. After my recent experiments I'd recommend leaving the GUI out of the picture for as long as possible, and implementing it in a scripting language instead of C++ - I find it a much more productive way of developing, plus your software is availible for people who don't want or can't use GUIs with no extra work. cheers, dave

On Fri, 2004-07-30 at 06:12, Steve Harris wrote: I have a document entitled "do we really need another modular synth?" waiting to go along with the release for just this. :D In short: - polyphony this is the big one, it eliminates all but ams - performance - ams is a _terrible_ CPU hog, especially when it goes polyphonic. I assume this is because it does everthing at audio-rate. Whatever the reason, ams is too much of a CPU hog to be useful to me personally, and the audio code is so intertwined with QT I gave up on hacking it long ago. plus, I have had minor talks on the ams list about this stuff, and those developers are heading in the exact opposite direction of myself - less generic, special inter-module data paths hidden from the user (which I think is an awful idea for the record), and a special ams-specific plugin format with all the bells and whistles. I wish them nothing but the best, but their goals don't coincide with what I need. "Scratching an itch" and all that. I need a good flexible, polyphonic LADSPA-using modular synth, and one doesn't exist. So........ Done and done, thanks to you and liblo. Well.. we need a way to have LADSPA plugin GUIs... DSSI is a LADSPA-like plugin format with GUIs.... 2 and 2. I never understood why you chose to make DSSI "soft synth" specific to be honest. Can DSSI not solve this problem? I've considered taking a look at those old xml ladspa gui proposals from Paul, but I assume there's some reason noone supported them. For the record, the fact that DSSI UIs talk to the _HOST_ via OSC is very, very cool for me, because that means my synth engine can still run over the network and not deal with GUI issues, which I don't think VST can do. Anyway. on plugin GUIs are alright, but for complicated patches they simply take up too much room. I admittedly work at a lower level than your average nord user probably does though. I planned on going the galan build-your-own-custom-control-panel route - I've never actually found the "buncha sliders" LADSPA GUI approach to hinder productivity anyway, sliders work for me. GUI's would be nice though.. -DR-

On Fri, 2004-07-30 at 16:13, Steve Harris wrote: That's okay, I don't like UI-on-the-module modulars anyway, I just want to be able to click on a module to get a GUI window, like ams (except with custom GUIs of course) Well, that's true. Anyway, it's a non-problem, because it sounds like DSSI will suit my needs just fine. If implemented transparently, the only difference between LADSPA plugins and DSSI plugins in my synth will be the fact that LADSPA plugins have crappier generated UI's. Since DSSI wraps LADSPA, that's quite nice, because if it's annoying that a certain module's UI sucks, someone somewhere will DSSI wrap the thing and fix the problem. -DR- -DR-

On Fri, 2004-07-30 at 18:07, Steve Harris wrote: Actually I've used the Nord editor (not extensively, but I've played). It is very nice indeed, but like I said complicated patches just take up too much space, especially when you work at a "lower level" so to speak (with lots of amps, and scaling, etc). Think of an average Pd patch, except with 400x300px modules for everything. Hardly feasible. Exactly. Hey, if someone wants to pursue the controls-on-module thing, they're more than welcome to write their own frontend. :) -DR-

Last Friday 30 July 2004 19:22, Dave Robillard was like: I'm with you on this one Dave. I think there isn't much point in developing a new sound generation app _unless_ it takes advantage of existing developments in the LAD arena. I don't like monolithic apps generally, although I do appreciate that it can use less system resources to run one big application rather than 3 small ones via JACK. Having realised that LADSPA does have all the bits you need to make a synth, it would seem logical to put it all together in a LAD-standards-compliant package (inasfar as those standards can be said to exist). likely to meet my compositional needs, especially as you are canvassing opinions on this list so openly. I'll be fascinated to see what you come up with and look forward to beta-testing it when the time comes. Thanks for bothering. tim hall

On Friday 30 July 2004 05:38 am, Dave Griffiths wrote: -snip- [screeching tires] Where can I find out more about this? What's it called?

On Thu, 2004-07-29 at 23:29, Rob wrote: Try AMS (alsamodular.sf.net). It has really good MIDI mapping, you can move a controller and it will show up/hilight in the list, then you can pick what param to bind it too. I plan on having the ability to right click on a module port and select "Bind MIDI Controller" from the menu, and having a dialog pop up that allows you to select the controller (moving the physical controller will select it). Would that work for you? This is just frontend stuff which isn't my focus at the moment (engine first), but I still like to hear opinions -DR-

in the package now is a huge tutorial by Mark Polishook that is very good to get started. additionally, David Cottle recently updated his enormous teaching tutorial and it's available online but you have to email him to ask for it until he feels it's "done" - d.cottle(a)utah.edu or cottle(a)cerlsoundgroup.org also look here: http://www.psi-o.net/pseudonym/introduction.php -- _________________________________________________________________ Jonathan Segel -- MAGNETIC -- PO Box 460816 S.F. CA. 94146-0816 jsegel(a)magneticmotorworks.com <-----> magsatellite(a)yahoo.com http://www.MagneticMotorworks.com

On Fri, Jul 30, 2004 at 09:10:32 +0100, tim hall wrote: pitchwheel? (seriously) DLS or GM defines a standard range for pitchweel, so you could write/beg/borrow/steal some code to send a onetime pitchbend message over alsasequencer that would retune all the synths to a particular A tuning. Assuming the soundfont engine supports pitchbend, but I would imagine it does. FWIW my "less trivial" DSSI synth example supports retuning A, but in all other ways its completely useless :) - Steve

On Fri, 2004-07-30 at 06:22, Dave Griffiths wrote: Things should support MTS (MIDI tuning standard), then you can set your tunings from anything (including scala which has MTS support), or write crazy apps to generate tunings, etc. -DR-

On Fri, 2004-07-30 at 06:02, Steve Harris wrote: That's what I do, but every time you change something in FluidSynth (ie load a soundfont) you have to get your mini-app to send another pitchbend message, and more importantly if you actually use the pitch bender it really screws everything up. Hassle. -DR-

Last Friday 30 July 2004 11:02, Steve Harris was like: I was so hoping you wouldn't say that :-] It's probably not beyond my ken to work out the appropriate value to bend the notes, and failing any other suggestions, this is surely what I shall do. Thanks for the advice. tim hall

Last Sunday 01 August 2004 06:35, Dave Robillard was like: I'd much prefer to Do It Right, unfortunately I don't really understand what you're suggesting here so well. How do you write an alsa seq filter, what should I be looking at? If it's that simple, I'll happily give it a go. Thanks for the suggestions. tim hall

On Fri, Jul 30, 2004 at 01:27:16PM -0400, Dave Robillard wrote: *cough* yes we do, DSSI. It accepts alsa-seq format MIDI structs. - Steve

On Fri, Jul 30, 2004 at 04:58:41 -0400, Dave Robillard wrote: Yeah, sure, but you may as well make it pay attention to MIDI too (or have another version that does), its very easy and will be useful to more people. NB writing a DSSI plugins is more effort than a LADSPA plugin - at least for me, but we tied to make simple things still simple-ish. - Steve

On Fri, 2004-07-30 at 13:48, Thorsten Wilms wrote: You could fake it, but it would be really complicated, and not that useful, since everything you wanted to do would have to be explicitly coded into the modular GUI, which doesn't make for a very useful programming environment. However, like Steve pointed out DSSI does MIDI. So.. it is possible. And I'm seriously considering it (using MIDI-over OSC to talk to the engine) I see. You mean patch in the 'select patch number on the synth' sense, not the Pd sense. As long as the assemblies are kept in seperate files and assemblies that contain others only reference the file (and not actually include it), I don't see why it wouldn't work.. (unless of course you change the inputs/outputs of your sub-assembly, which no versioning system is going to resolve!) Oh, sorry. I assumed you were the author. Hmm.. new GUI looks interesting. I just want the ability to EASILY assign a sample to a certain key (ie midi note) and have it play without pitch scaling. A mixer like hydrogen is crucial too, so you can adjust the relative volumes and pan and whatnot. I realise specimen is targeted toward pitched-instrument sampling, but there's no reason it can't be suitable for percussion sampling with a little UI consideration. Getting off-topic, if you really want to hear my thoughts on specimen GUI, feel free to mail me personally -DR-

On Friday 30 July 2004 01:27 pm, Dave Robillard wrote: -snip- -snip- Heheh, thanks guy, I hadn't thought of that. FWIW, one can handle binaries with CVS too. Files have to be flagged as such (or CVS has to be configured to associate file extensions for binaries) and it takes a lot more space than text, but it works. So, how about having the "save" bits be smart enough to hand things off to CVS? Could be the mother of all patch librarians.

On Fri, 30 Jul 2004 12:54:47 +0200, Frank Barknecht wrote I would contest (as I always do) that a modular synth is not equivalent to a node based programming language. They are different things. It's nice to be able to group modular units together into voices that you can reuse later, but I don't see ladspa plugins being the same as pd externals at all. I guess what I'm saying is that it's useful, but lacking this feature in a synth does not make it unusable. cheers, dave

On Fri, 2004-07-30 at 06:54, Frank Barknecht wrote: Now that you mention it subpatches are really important to a truly useful modular synth. Maybe subpatch ability can't just be left to the frontend like I initially thought. I'll put some thought in to it, thanks. -DR-

Just as a point of reference, audiomulch has a neat timeline feature where you can draw filter controls etc. May be worth checking out http://www.audiomulch.com/info.htm -ry