Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

by Taybin Rutkin

How should a host deal with a port that is MOMENTARY, but not TOGGLED? What would the UI be? Taybin -----Original Message----- From: Tim Goetze <tim(a)quitte.de> Sent: Mar 8, 2004 1:06 PM To: The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu> Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff) ok, suppose we say only MOMENTARY, and one-shot triggering is always rising edge. now we have another problem: Taybin is pretty adamant in requiring MOMENTARY to imply TOGGLED. this means we'll always need another port to transmit the velocity value for note-on and similar events. fine, no problem? apart from this meaning a waste of resources, how do we transmit two such impulses in successive run() calls? simply split the run() call in two? at what a waste of resources do we arrive then, for the doubtful pleasure of having a 'simple' model. beats the intention of simplicity if you ask me.

21 years, 6 months

[linux-audio-dev] ICMC 2004: Online Submissions for papers, demos, and posters now online

by tae hong park

Please pardon cross postings. ICMC 2004 : Online submissions for papers, demos, and posters are now fully functional and available at http://www.icmc2004.org. Please follow instructions on the website. Thank you. Best Regards, Tae Hong Park, ICMC 2004 Publicity Chair

21 years, 6 months

Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

by Taybin Rutkin

That can't be. What would a MOMENTARY output port mean? Taybin -----Original Message----- From: Matthias Nagorni <mana(a)suse.de> Sent: Mar 8, 2004 11:14 AM To: Taybin Rutkin <taybin(a)earthlink.net>, The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu> Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff) On Mon, 8 Mar 2004, Taybin Rutkin wrote: > The presence of both MOMENTARY and TRIGGER seems redundent. TRIGGER means that it's reset to 0 after one call to run() or run_adding()? That'll happen so fast, the user won't even notice the UI change. If TRIGGER is for scale values, how will it scale if it's set to 0 after every call? The distinction between them is overlapping and confusing. It looks like TRIGGER is for input and MOMENTARY for output ports. Matthias -- Dr. Matthias Nagorni SuSE Linux AG Maxfeldstr. 5 phone: +49 911 74053375 D - 90409 Nuernberg fax : +49 911 74053483

21 years, 6 months

[linux-audio-dev] Possible LADSPA port path convention

by Steve Harris

Something that was suggested for GMPI, and might be applicable for LADSPA is a convetion where port names can be written as paths, eg for a delay line you might have "delay/base delay (ms)" "delay/feedback (%)" "lfo 1/ammount (%)" "lfo 1/wave" "lfo 1/frequency" "lfo 2/ammount (%)" "lfo 2/wave" "lfo 2/frequency" this would allow the host to group the controls logically when building the UI, eg. tabbing them, and friendlier OSC reflections of plugins. It would require that lexical /'s be escaped, but other than that it should be transparent. Its only worth adding if hosts would implement something using it though, as it would cause a bit of disruption, there are about 30 exisiting ports with /'s in them. A different character could be used, but / seems like the obvious one. - Steve

21 years, 6 months

[linux-audio-dev] [ANN] galan-0.3.0_beta5 released

by torbenh＠informatik.uni-bremen.de

galan-0.3.0_beta5 is released. For those who know it already: One of the new features include cloning. you can now select a bunch of components and clone them. (This will be changed to a full blown copy/paste mechanism soon) And the polyphony option will be added soon. galan is a modular synthesizer similar to SSM and AMS. The difference is that you build the schematics in one window and have the controls in another window. So your synth UI is not cluttered with the schematics. galan also supports subpatches. You can add patches from the library to your current patch with 2 mouseclicks. the LADSPA adsr can be used for real note-on note-off behaviour. And with the voice allocator it is already possible to build polyphonic synths. I will refine that process somwhat. But it already works. When you have setup your schematic and placed the controlling knobs and sliders on your control panel, you can draw a custom background for the ControlPanel and import the painted picture into galan. The knobs now support alpha transparency, so they should integrate onto every background. galan supports jack and alsa sequencer. You can open any number of ports you would like. The internal sequencers can sync to jack-transport. galan also supports LADSPA. You will have all LADSPA effects handy you normally use. And you will be able to setup a nice Interface for your Effects. You would then save them to your sheet library, making them 2 clicks away. So wiring a jack-inport and another jack-outport to your favorite plugin, is done in a few seconds. It even supports the first jack-midi patch (although only as a synth and as the patch changed recently, there will be no sequencer around :) perhaps the next patch. get it at http://galan.sf.net and look at http://galan.sf.net/anti-aliased-knobs.png cause this is how it looks like. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

21 years, 6 months

Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

by James W. Morris

I've found these ladspa extension threads very interesting, despite half of it going over my head. But it's interesting to see you all thrash it out. That's one advantage of being the sole programmer of a project, I can just get on with it how ever I like, especially as it's not something many people use and certainly not rely on. I've downloaded the diff & host.c & drive.c examples Tim posted - which I'll look at in time....still got other stuff to do first.... >From: Tim Goetze >Date: Mon, 8 Mar 2004 18:30:01 +0100 (CET) >i'll try to explain in terms of UI controls: > >MOMENTARY: a push button, sending 'yes' when pressed and 'no' when >released. > >TRIGGER: a push button, sending 'yes' only at press *or* release, and >'no' at any other point in time. In wcnt I have an input and output type which is a 'trigger'. it is ON for one sample only. That's it. For example, note on and note off come from two seperare trigger outputs. This means that the adsr can be retriggered without it thinking it's a note off. but then I don't use any midi messaging for such events. (There is also a 'state' which can be 'ON' for many samples, but I've not found any use for this as far as inputs and outputs go, except perhaps displaying whether something is 'playing' - which nothing does) My concept of a trigger came from using a korg ms20 and ms50 expander, and I think I may have recorded a trigger signal to see what shape it was, and it was certainly not like a single sample at full amplitude, but generally it has the same effect. James. ~(sirromseventyfive)~ _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

21 years, 6 months

Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

by Taybin Rutkin

Please consider MOMENTARY from a UI point of view. A MOMENTARY would have to be a button or button like object (ncurses). In that case, the values its use implies are either hardcoded in the plugin, or previously chosen by the user. Being boolean is not a limitation on the use of the push button. Taybin -----Original Message----- From: Tim Goetze <tim(a)quitte.de> Sent: Mar 8, 2004 11:19 AM To: Taybin Rutkin <taybin(a)earthlink.net>, The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu> Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff) [Taybin Rutkin] >Please make MOMENTARY imply TOGGLED. This lets older hosts degrade >gracefully. a recommendation, yes i think that would be very sensible indeed. please consider that implying TOGGLED makes MOMENTARY a '1 or 0' valued control for all time, which is an unnecessary limitation. [Taybin Rutkin] >The presence of both MOMENTARY and TRIGGER seems redundent. TRIGGER >means that it's reset to 0 after one call to run() or run_adding()? >That'll happen so fast, the user won't even notice the UI change. >If TRIGGER is for scale values, how will it scale if it's set to 0 >after every call? The distinction between them is overlapping and >confusing. TRIGGER is meant to accommodate MIDI and other mechanical trigger sources, it's not exclusively tailored for display user interface elements. there are a number of convenient ways to represent it on-screen though, like the good old peak meter. in fact there already are plugins implementing the TRIGGER behaviour. it needs official status. more opinions please? amicalement, tim

21 years, 6 months

Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

by Taybin Rutkin

The presence of both MOMENTARY and TRIGGER seems redundent. TRIGGER means that it's reset to 0 after one call to run() or run_adding()? That'll happen so fast, the user won't even notice the UI change. If TRIGGER is for scale values, how will it scale if it's set to 0 after every call? The distinction between them is overlapping and confusing. Taybin -----Original Message----- From: Tim Goetze <tim(a)quitte.de> Sent: Mar 7, 2004 7:39 PM To: linux-audio-dev(a)music.columbia.edu Subject: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff) attached you'll please find three files: * a patch moving ladspa.h 1.1 to 2.0 * a program showing how a host evaluates 2.0 extensions * a thoroughly documented example plugin making use of the extensions changes to the patch with respect to the last version include consolidation of the extended port info into a dedicated structure. also included is a warning note concerning the deprecation of the 1.1 default value hints and some minor clarifications. the patch defines HINT_MOMENTARY as asked by Taybin and Steve. it also credits Taybin now (Steve already being credited). - the example plugin is written with the intention to show, in all its sometimes gory detail, how ladspa works 'from the plugin side'. the plugin is fully operational in hosts implementing either version of the standard. (it doesn't even sound so bad at all :) there are a number of more elegant ways to accomplish what the plugin source does, but these have all been ignored for the sake of showing exactly how things are coming together in ladspa. - if you expect the extension to make a plugin author's life harder by a significant amount, i would like to ask you to go over the source code of the example plugin and see for yourself. all the places where the plugin refers to the 2.0 incarnation have been marked as such. i'm confident you'll agree that words like 'invasive', 'incomprehensible', 'bloated' or 'complicating' are not doing the extension justice. i would also like you to consider that it is up to you, either plugin or host author, to altogether ignore the extension and still come up with something perfectly useful. you can always extend your work to make use of the extension at a later date. all this takes is added code, with no changes to what you already have. - my apologies offered for the obnoxious use of the '2.0' version tag for this proposal. for sheer lack of fantasy, typing laziness and a number of other bad habits, i couldn't come up with something better. amicalement, tim ps: it is hoped that the example plugin source will be helpful to aspiring plugin authors, no matter the fate of the extension proposal.

21 years, 6 months

Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

by Taybin Rutkin

Please make MOMENTARY imply TOGGLED. This lets older hosts degrade gracefully. Taybin -----Original Message----- From: Tim Goetze <tim(a)quitte.de> Sent: Mar 7, 2004 7:39 PM To: linux-audio-dev(a)music.columbia.edu Subject: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff) attached you'll please find three files: * a patch moving ladspa.h 1.1 to 2.0 * a program showing how a host evaluates 2.0 extensions * a thoroughly documented example plugin making use of the extensions changes to the patch with respect to the last version include consolidation of the extended port info into a dedicated structure. also included is a warning note concerning the deprecation of the 1.1 default value hints and some minor clarifications. the patch defines HINT_MOMENTARY as asked by Taybin and Steve. it also credits Taybin now (Steve already being credited). - the example plugin is written with the intention to show, in all its sometimes gory detail, how ladspa works 'from the plugin side'. the plugin is fully operational in hosts implementing either version of the standard. (it doesn't even sound so bad at all :) there are a number of more elegant ways to accomplish what the plugin source does, but these have all been ignored for the sake of showing exactly how things are coming together in ladspa. - if you expect the extension to make a plugin author's life harder by a significant amount, i would like to ask you to go over the source code of the example plugin and see for yourself. all the places where the plugin refers to the 2.0 incarnation have been marked as such. i'm confident you'll agree that words like 'invasive', 'incomprehensible', 'bloated' or 'complicating' are not doing the extension justice. i would also like you to consider that it is up to you, either plugin or host author, to altogether ignore the extension and still come up with something perfectly useful. you can always extend your work to make use of the extension at a later date. all this takes is added code, with no changes to what you already have. - my apologies offered for the obnoxious use of the '2.0' version tag for this proposal. for sheer lack of fantasy, typing laziness and a number of other bad habits, i couldn't come up with something better. amicalement, tim ps: it is hoped that the example plugin source will be helpful to aspiring plugin authors, no matter the fate of the extension proposal.

21 years, 6 months

Re: [linux-audio-dev] TAP-plugins reverb presets (fwd)

by Tim Goetze

[Fons Adriaensen] >On Fri, Mar 05, 2004 at 09:56:01PM +0100, Tom Szilagyi wrote: > >> I think the "dead end" has just been reached... > >Yes. Steve has made his position very clear: he opposes any change >to ladspa.h. Much as I respect Steve for all his contributions to >Linux Audio, I think this is misguided and I do not share his >opinion on what is 'meta' and what is not (and I sort of enjoyed >Tim's posting an this subject). thanks. i haven't given up on Steve yet. i admit he's stubborn, but that simply behooves a good brit. he's also a bright mind, so he'll realize sooner or later when he's supporting the wrong ideas. unfortunately, his support for the ladspa 1.1 default value hack back in the day has shown that 'sooner or later' sometimes means 'after the milk has been spilled'. maybe he's still shocked by the damage done to ladspa then, and his consequence is to keep ladspa from changing at all now. i do not know. (my apologies offered, Steve, for this rude, amateur public attempt at understanding your motives.) [good points about the other proposals elided] >3. Then there is Tim's proposal, which allows for arbitary 'scale >points' and which I think is clean and elegant, but that has the >disadvantage of being much more invasive, as it introduces new >fields and structs. And that IMHO means that its chances of being >accepted as a de facto standard are impaired - there will inevitably >be some commotion before this happens, and Tim's idea, even if it >is in fact straightforward and logical, offers much more lines of >attack to those that would resist any change. And that is not >because there is any real problem with it, but only because it is >a lot more ambitious than what I dared to propose. thank you for the favourable review. i would prefer the term 'expansive' instead of 'invasive' for the patch: it doesn't change a thing about ladspa as it is now. you can patch all or only some of your local copies of ladspa.h, issue a 'make' for the projects affected, be they host or plugin, without experiencing any problem at all. i've also tried to show that there is no mutual exclusion between the patch and RDF; in fact it remains to be shown that there even is friction between the two. on the contrary, they'll mix well. >To my own surprise, I find myself talking politics. This is starting >to look like the US presidential campaign, so I'd better stop. let's thank god this is not even half as grave as the US choice of president. :) to expand on the political aspect on this: since we'll never agree on what goes into it at what does not, by far the most democratic option is to let everyone have their *positive* will. this is what the patch does: it realizes all concepts wished for so far by all the plugin and host authors present on this list. people who have gone over the patch will agree that it does so without bloating ladspa.h, or if you prefer hard numbers: -rw-r--r-- 1 lad lad 27447 Mar 5 15:21 ladspa.h.orig -rw-r--r-- 2 lad lad 31478 Mar 6 01:09 ladspa.h the patch even removes the need for the default value hack in ladspa.h in the long run. let's also not forget the most invasive change the patch introduces is the TRIGGER and/or MOMENTARY hint bit; this is the only thing that *can* cause problems between a 2.0 plugin and a 1.1 host, and it is being agreed upon (in essence, not in implementation) by everybody so far. - once again, my apologies offered for a long-winded post. i would like to conclude it with another political statement: live and let live. be glad your wishes can be realized, and don't dispute the right of others to see theirs realized as well. vriendelijk, tim

21 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev