On Wed, 2003-04-16 at 16:03, ian wrote: Yep, that's how I did it. But, surprise! Some weird ones use AUDIO signals for control data (oscillators use it for amplitude). So, to hack around this, I check to see if the audio port is bounded by below or above. I have it setup like this, I load a plugin for left/right if it is a mono plugin (my app is stereo). If it is stereo, I will load it as stereo fine. That's my only place to learn. I basically borrowed the code from the demos and am using it. I fixed up the majority of leaks it had. Oh I don't want to limit them at all, but some plugins refuse to work at all, and mangle the effect chain! Those aren't cool, they just don't work properly in my app. Of course, it might be a bug somewhere in my driver.. I only just made this today... and I am still working on it pretty heavy right now. I have now gotten almost 90% of the ones that won't work properly to filter out. Anyone use Dj Flanger? Is there something you have to do to use this plugin? When I use it it makes terrible noises. I plan on doing alot of LADSPA plugins. Why? It's so simple API to use. It has only taken me an afternoon to build a host app and even build my GUIs at run time for it with FLTK. It's great! And alot of those F/X sound WILD!

On Wed, Apr 16, 2003 at 04:56:20 -0400, Nick Tsocanos wrote: There is a proposed hint to cover this, it would indicate that an audio rate input was actualy intended for control type signals. There are some *cough* known bugs in many LADSPA plugins. That one works AFAIK. Theres nothing special about it. Cool :) Incase you haven't seen it I recommend by XML LADSPA build system, it makes writing plugins very easy, by taking away all the tedious struct mangling. I had a half written tutorial, but I'm not sure what I did with it. - Steve

Yes, I can see this already. So far, I think LADSPA needs some tweaking, but it works pretty good. I think every plugin should implement every function mandatory. Why? When I first started, I executed activate() deactivate() run_adding() without checking if they were NULL. Since I need run_adding() and not all plugins implement I had to make my own run_adding() driver. Not really hard to do, but, if run_adding() was mandatory in all plugins, it would be less work overall. What would be really nice, would be hints that could be used programmatcially by the program so that it could switch it and determine exactly how the plugins was intended to be used. Particularly, this would be easy, would be a bit mask, that specified if it was a synthesis flag, or an effect processor, or something else. One boolean comparison and you could determine how a plugin could be used. I let all plugins through now, but some work very strangely in my app. Some don't seem to work at all. Now, I have realized one thing: not all LADSPA plugins are good and will initialize themselves. So, I have to make sure I initialize it with the default hints, or it will blow up, lock up my system with massive buffer under runs because the plugin is making NANs or massive denormals or doing something just plain naughty.Some of them will come up in a random state and more or less they will lock up my system. Hehe. What I haven't figured out is why there are NO CHORUS plugins. I love chorus, it is my favorite effects. I have written dozens of Chorus and Chorus variation effects. So, my first plugins are going to be Chorus boxes. This is weird, it seems the entire world neglects Chorus, not just LADSPA. If I recall, when I played with Reason, it didn't have Chorus either. Rebirth didn't have Chorus. Waddup with that? Chorus is the BEST effect for analog signals. Detuned oscillators and a chorus box make PHAT PHAT PHAT sounds.

On Thu, Apr 17, 2003 at 07:19:48 -0400, Nick Tsocanos wrote: It comes free with the source ;) http://plugin.org.uk/ - Steve

Ok, I understand what you mean. It really isn't hard! It just came as a surprise the first time I ran activate on a function that wasn't there hehe. I didn't read in the API header that is was optional. It is really not a high priority for me to have this, I can live without it it's fine. That's why I am very lenient on how I filter them out now. Since my program is a Tekno Composer, and tekno artists are known to do weird things, I let them use them. If they don't work right, well, maybe it will actually produce an effect that is cool after all. So, yep, I'll let them connect a Variable slope oscillator now, but if it screeches and makes there ears hurt, don't sue me... Umm, no, this one I know what I am talking about! Dyson Compressor would not work unless I set the control values to defaults. For some reason, it says it can take 0 for some parameters, but if I put zero in it it blows up. Now it could be my app! I don't know. I remove all denormals beforehand, so I know it's not denormals. It could be making lists of NANs and those will make the system grind to a halt (massive buffer underruns). Or, it's the plugin! Since I am just hacking at this (I am only self-taught, I don't know how people learn all this DSP stuff.. I learn by studying other's code, and reading books, and reading stuff on the internet) I can't say with confidence who is to blame. All I know is if I plug certain plugins in without setting the default values my app blows up hehe.

Oh hehe! I didn't see that one! I have about 50 or so plugins now. It's totally awesome. I did donwload your source and was at your page so I will look for that XML thing and figure out how to use it. I didn't realize you were THE Steve hehe... I am going to make my Moog filter into a plugin as my first attempt. I think it sounds pretty good and the resonance is really good on it. I modeled it directly from the analog-s-domain transfer function given by stilson using a bilinear transform, and double sample it for stability. It appears it only works properly if the coefficients are doubles. I can also use it's envelope for a 303 kind of filter, but guess what?! CMT has a VCF303! Awesome! I am like a kid in a candy shop right now. So many possibilties unveiled through these plugins. I have figured out mostly what the problem was with unitialized plugins. The problem is I was not zeroing out my controlPorts when creating the plugin, and it would come up with whacky values. Only some plugins don't work correctly. Most work ok even with random values (but they make really really strange sounds). Also, I think that on some plugins, it expects input to be normalized to [-1,1] and, I am not clipping at the point I run the plugins, because I am using a dither() algorithm which does the hard clipping when quantize to 16-bit integers (for sound output). Now the only one weird problem is that some plugins sort of go crunchy when I set a control port value to certain numbers. Dyson Compressor went ballistic when I set one of the knobs to zero. Don't think I am criticizing any plugins! It is most likely my driver code. I have only been working on it for a day now and it is still pretty buggy in when it installs a plugin but I have hammered out most of the problems now. I am really thankful for these plugins, and if they have bugs, I can help to fix them or tell the author what I find. I am sure it is a problem with my app still, the gain has always been a major problem, and so has clipping.

On Thu, Apr 17, 2003 at 12:06:12PM -0400, Nick Tsocanos wrote: It's very simple, just a polynomial sin aproximation used as a waveshaper. Good :) it was an accident, I was trying to implement the dj flanger from a description and misunderstood. I left it in there as I'd allready built it. Most of the tricks come from papers, but much of it is pretty obvious, once you know the basics. Oh, and a lot of trial and error :/ The music-dsp mailing list is a good source of expert advice. - Steve