Re: [linux-audio-dev] Additional LADSPA hints
On Wed, Jan 15, 2003 at 10:23:37PM +, Steve Harris wrote: > That sounds useful, but its a seperate issue. I cant think of a way of > generalising it... maybe OPTIONAL? i.e. this plugin will still do > something useful if this port isn't connected. I just might be a bit late giving my 2cents to this discussion, but I rather read this list on a non regular basis, too much to do at university... Anyway, why a introduce a ladspa hint for such specific features. Anyway the Sidechain port has a label called "Sidechain", so every host wanting to provide special support for the label can just check for it and use it. In GLAME you can just build up a custom network integrating whatever effects and connecting them how you like. And than just save it and use it as new effect. Cheers, Alex
Re: [linux-audio-dev] Additional LADSPA hints
On Tue, Jan 21, 2003 at 11:02:08 -0800, robbins jacob wrote: > However, it seems that plugin writers are more comfortable interpreting > port type=audio to mean that the rate of the port is audio rate. Steve > suggests that it is splitting hairs to try to absolutely determine whether > an audio-rate port is for audio or control content. If this is the case > then we should just leave 2 port types and add a hint for audio-rate ports > that they should be used for control data. > > I feel I must warn that this will make the ladspa_port_types audio vs > control a little misleading to people when they first read the header. If > the port type is chosen to be audio and not data then the port should be > for audio and not data, right? In short I think adding a third port type > would keep the header self-consistent, whereas adding a hint that overrides > and reverses the port type is twisting the standard to match current useage. Not at all, the /type/ indicates what data you should expect (a vector of LADSPA_Data or a single value), whereas the hint indicates likely usage. Continuous control is a common term than implies a stream of data. In any case this will not be directly visible to users. - Steve
Re: [linux-audio-dev] Additional LADSPA hints
To my own surprise I have to object to the suggestion: /* AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled by a high time res. slider or control data, but shouldn't be connected to the next audio signal by default. I can't think of any simple examples off hand, but combined with MOMENTARY it could be used for sample accurate tempo tapping. */ As is see it, this declares that an audio port should be used for control data. Yes. At present, ladspa allows two types of port: LADSPA_PORT_CONTROL (one value per block) LADSPA_PORT_AUDIO (array of values per block) However, some plugin authors (myself included) wanted finer control over the parameters, so we 'overloaded' the AUDIO port to allow per-sample control data. This has been used in many libraries: cmt, swh-plugins, blop, and it works fine in hosts that allow direct wiring: SpiralSynthModular, AlsaModularSynth, gAlan. However, other hosts such as Ardour and Ecasound do not have the same direct wiring functions, and instead treat any AUDIO ports as exactly that (making them available as Effect Sends or similar). The purpose of the new hint is to accommodate these hosts: LADSPA_PORT_CONTROL (one value per block for control data) LADSPA_PORT_AUDIO (array of values per block for audio data) LADSPA_PORT_CONTINUOUS_CONTROL (array of values per block for control data) This is what I'm getting at: the original suggestion was to introduce a LADSPA_HINT for continuous control which would be applied to ports of type LADSPA_PORT_AUDIO. I think that this is misleading because I interpret port type = audio to mean that the port is for audio content as opposed to control content. I agree with the proposal as you present it here, adding a new port type (not a new hint). However, it seems that plugin writers are more comfortable interpreting port type=audio to mean that the rate of the port is audio rate. Steve suggests that it is splitting hairs to try to absolutely determine whether an audio-rate port is for audio or control content. If this is the case then we should just leave 2 port types and add a hint for audio-rate ports that they should be used for control data. I feel I must warn that this will make the ladspa_port_types audio vs control a little misleading to people when they first read the header. If the port type is chosen to be audio and not data then the port should be for audio and not data, right? In short I think adding a third port type would keep the header self-consistent, whereas adding a hint that overrides and reverses the port type is twisting the standard to match current useage. --jacob robbins. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: [linux-audio-dev] Additional LADSPA hints
On Sun, Jan 19, 2003 at 06:44:36PM +, Steve Harris wrote: > My main concern abou htis hint is that it artificially introduces a > distinction that isn't really there. Its fine as long as no modular host > ever prevents me form wiring an audio output to hinted continuous control > input or vice-versa. i dont consider evaluating that hint in gAlan... its fine with me...
Re: [linux-audio-dev] Additional LADSPA hints
On Fri, Jan 17, 2003 at 10:28:44 -0800, robbins jacob wrote: > To my own surprise I have to object to the suggestion: > /* > AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled > by a high time res. slider or control data, but shouldn't be connected to > the next audio signal by default. I can't think of any simple examples off > hand, but combined with MOMENTARY it could be used for sample accurate > tempo tapping. > */ > > As is see it, this declares that an audio port should be used for control > data. I oppose because it is ugly to declare a port one thing in its > PortDescriptor only to reverse this in the PortRangeHint. Furthermore, this > ugliness is likely to cause problems in hosts that do not parse this hint > value*. I really dont understand where your coming from with this. There are allready several LADSPA plugins that take control data from audio ports, its not an unusual thing tho do. This hint would reduce potential user confusion if anything as single stage plugin appliations would stop presenting them as audio ports. My main concern abou htis hint is that it artificially introduces a distinction that isn't really there. Its fine as long as no modular host ever prevents me form wiring an audio output to hinted continuous control input or vice-versa. - Steve
Re: [linux-audio-dev] Additional LADSPA hints
On Fri, 17 Jan 2003 10:28:44 -0800 "robbins jacob" <[EMAIL PROTECTED]> wrote: > To my own surprise I have to object to the suggestion: > /* > AUDIO_RATE_CONTROL. Hints than an audio control should/could be > controlled by a high time res. slider or control data, but shouldn't > be connected to the next audio signal by default. I can't think of any > simple examples off hand, but combined with MOMENTARY it could be used > for sample accurate tempo tapping. > */ > > As is see it, this declares that an audio port should be used for > control data. Yes. At present, ladspa allows two types of port: LADSPA_PORT_CONTROL (one value per block) LADSPA_PORT_AUDIO (array of values per block) However, some plugin authors (myself included) wanted finer control over the parameters, so we 'overloaded' the AUDIO port to allow per-sample control data. This has been used in many libraries: cmt, swh-plugins, blop, and it works fine in hosts that allow direct wiring: SpiralSynthModular, AlsaModularSynth, gAlan. However, other hosts such as Ardour and Ecasound do not have the same direct wiring functions, and instead treat any AUDIO ports as exactly that (making them available as Effect Sends or similar). The purpose of the new hint is to accommodate these hosts: LADSPA_PORT_CONTROL(one value per block for control data) LADSPA_PORT_AUDIO (array of values per block for audio data) LADSPA_PORT_CONTINUOUS_CONTROL (array of values per block for control data) Hinting a port with this new hint would allow such a host to treat these ports as per-sample controls, and not audio ports, and perform the right actions. It would require existing plugin libraries to change their hints. > I oppose because it is ugly to declare a port one thing in its > PortDescriptor only to reverse this in the PortRangeHint. Furthermore, > this ugliness is likely to cause problems in hosts that do not parse > this hint value*. PortRangeHints, if given, only specify minima and maxima for an input port, and are semantically the same for both port types. Can you elaborate on this? > I believe that the true intention here was to undo the requirement > that data ports can only have one value per run() block, but the > author realized that undoing that requirement has significant > implications. The primary problem occurs when the plugin assumes a > particular control is continuous but the host abides by ladspa.h v1.1 > which does not allow more than one control value per block. The plugin > will treat that control port's data pointer as if it pointed to an > array of the blocksize passed to run(), but the host will have only > allocated a single value so there is a memory error. The host should allocate a single value for ports hinted as LADSPA_PORT_CONTROL, and allocate an array of sample_count for those hinted as LADSPA_PORT_AUDIO, as per ladspa.h. For ports hinted with the new hint, an array of sample_count should be allocated. > (*)I argue that turning audio ports into data ports will cause enough > host incompatibility problems that you might as well do it correctly > IF you really feel it's worth it to add this feature. Here are some > incompatibilities which arise from using audio ports as continuous > control ports: > -the host doesn't parse the hint and sends audio to the control > resulting in caucophonous output. > -the host does realize it shouldn't send audio to the "audio" port but > > doesn't have a facility for sending control data arrays to audio > ports, so the user is unable to manipulate some of the controls on the > plugin. Plugin writers are more likely to use continuous controls for > important plugin features which warrant the extra detail, so > unmodified hosts will be unable to accomodate very useful plugins that > do who-knows-what. This is what we want to avoid. It is only a problem for hosts that automatically insert plugins into an audio stream. To do this, we need to make a distinction between AUDIO ports, and per-sample CONTROL ports and only use AUDIO ports for audio data. This is what the new hint would deliver. > Basically, introducing arrays of control data will force ALL > reasonable > hosts to adapt to handle that ability. So I believe we are better off > keeping ladspa.h straightforward and self consistent by eliminating > the strict single control value requirement and dealing with the > issues involved, as opposed to maintaining a false veneer of backwards > > compatibility by allowing use of audio ports for control data. I agree. But sometimes, per-sample control isn't needed and/or wanted (due to seldom changing values, cpu usage and so on). So I think having three hints is still needed. > What are the issues involved with eliminating one control value per > block? > I think that all you need to do is remove it and add a data port hint > CONTINUOUS which means the host _must_ attach that control port to a > whole block's worth of data for each run. As i said be
[linux-audio-dev] Additional LADSPA hints
To my own surprise I have to object to the suggestion: /* AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled by a high time res. slider or control data, but shouldn't be connected to the next audio signal by default. I can't think of any simple examples off hand, but combined with MOMENTARY it could be used for sample accurate tempo tapping. */ As is see it, this declares that an audio port should be used for control data. I oppose because it is ugly to declare a port one thing in its PortDescriptor only to reverse this in the PortRangeHint. Furthermore, this ugliness is likely to cause problems in hosts that do not parse this hint value*. I believe that the true intention here was to undo the requirement that data ports can only have one value per run() block, but the author realized that undoing that requirement has significant implications. The primary problem occurs when the plugin assumes a particular control is continuous but the host abides by ladspa.h v1.1 which does not allow more than one control value per block. The plugin will treat that control port's data pointer as if it pointed to an array of the blocksize passed to run(), but the host will have only allocated a single value so there is a memory error. (*)I argue that turning audio ports into data ports will cause enough host incompatibility problems that you might as well do it correctly IF you really feel it's worth it to add this feature. Here are some incompatibilities which arise from using audio ports as continuous control ports: -the host doesn't parse the hint and sends audio to the control resulting in caucophonous output. -the host does realize it shouldn't send audio to the "audio" port but doesn't have a facility for sending control data arrays to audio ports, so the user is unable to manipulate some of the controls on the plugin. Plugin writers are more likely to use continuous controls for important plugin features which warrant the extra detail, so unmodified hosts will be unable to accomodate very useful plugins that do who-knows-what. Basically, introducing arrays of control data will force ALL reasonable hosts to adapt to handle that ability. So I believe we are better off keeping ladspa.h straightforward and self consistent by eliminating the strict single control value requirement and dealing with the issues involved, as opposed to maintaining a false veneer of backwards compatibility by allowing use of audio ports for control data. What are the issues involved with eliminating one control value per block? I think that all you need to do is remove it and add a data port hint CONTINUOUS which means the host _must_ attach that control port to a whole block's worth of data for each run. As i said before, this kills backwards compatibility of hosts, but you are going to do that for the majority of hosts anyway if you reappropriate audio ports for control data and reappropriating audio ports is ugly. As to whether I support adding CONTINUOUS data ports and breaking host compatibility; i haven't written my host yet so yes i support it because it will be easy enough to implement (or so i think :) --jacob robbins. _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: [linux-audio-dev] Additional LADSPA hints
--- Jack O'Quin <[EMAIL PROTECTED]> wrote: > Steve Harris <[EMAIL PROTECTED]> writes: > > > > On Wed, 15 Jan 2003 18:13:35 + > > > Steve Harris <[EMAIL PROTECTED]> wrote: > > > > > > > AUDIO_RATE_CONTROL. Hints than an audio control should/could be > controlled > > > > by a high time res. slider or control data, but shouldn't be connected > to > > > > the next audio signal by default. I can't think of any simple examples > off > > > > hand, but combined with MOMENTARY it could be used for sample accurate > > > > tempo tapping. > > > > > > > > My comments: I really like MOMENTARY and RANDOMISABLE. > AUDIO_RATE_CONTROL > > > > could be useful, but might be painful for hosts to implement. I dont > have > > > > any particular use for it right now. > > > On Thu, Jan 16, 2003 at 02:38:53PM +0200, janne halttunen wrote: > > > Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? > > > > You'd have a buffer-full of samples and apply frequency shift to them, > > > which would change the length of that buffer, which you couldn't give to > > > JACK unless you do some rebuffering. > > > > No, I dont think so. An audio rate control is just one that has a value > > per sample, instead of a value per block. Its usful for things like FM > > frequency which can be changed very quickly. Hey, I just thought of a use > > for it ;) More uses: * Vibrato/Tremolo (sounds better with continuous control) * Fast transients (percussion synthesis) * Smoother response to erratic input (smoothing the output from a gui widget makes for a nicer 'feel') In short, I support the addition of this hint to LADSPA :) > > There's a syntactic ambiguity in the name AUDIO_RATE_CONTROL. Steve > uses it to describe a Controller which runs at Audio Rate (i.e. sample > clock speed). But, Janne understood it to mean a Controller *of* the > Audio Rate, which is not allowed. Maybe a different name > (CONTINUOUS_CONTROLLER?) would be clearer. Seconded. I think including 'AUDIO' in the hint would confuse matters. A short comment in ladspa.h could specifiy that 'continuous' means 'at audio rate'. Mike __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: [linux-audio-dev] Additional LADSPA hints
On Thu, Jan 16, 2003 at 10:19:38AM -0600, Jack O'Quin wrote: > There's a syntactic ambiguity in the name AUDIO_RATE_CONTROL. Steve > uses it to describe a Controller which runs at Audio Rate (i.e. sample > clock speed). But, Janne understood it to mean a Controller *of* the > Audio Rate, which is not allowed. Maybe a different name > (CONTINUOUS_CONTROLLER?) would be clearer. Yes, agreed. The names I used were just the ones I first thought of, there not necceserily any good :) - Steve
Re: [linux-audio-dev] Additional LADSPA hints
On Thu, 16 Jan 2003 16:35:37 + Steve Harris <[EMAIL PROTECTED]> wrote: > On Thu, Jan 16, 2003 at 05:31:56PM +0200, janne halttunen wrote: > > > No, I dont think so. An audio rate control is just one that has a value > > > per sample, instead of a value per block. Its usful for things like FM > > > frequency which can be changed very quickly. Hey, I just thought of a use > > > for it ;) > > > > But how can it be used for "tempo tapping" then? > > Tempo tapping is a way of determining the tempo of the musicians music, > you tap the button in time to the music and the software then uses that to > sync delays and similar effects. It doesn't do any time stetching. Ah, allright. Neat. :) janne
Re: [linux-audio-dev] Additional LADSPA hints
On Thu, 16 Jan 2003 10:58:40 -0500 Paul Davis <[EMAIL PROTECTED]> wrote: > >On Wed, 15 Jan 2003 18:13:35 + > >Steve Harris <[EMAIL PROTECTED]> wrote: > > > >> AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled > >> by a high time res. slider or control data, but shouldn't be connected to > >> the next audio signal by default. I can't think of any simple examples off > >> hand, but combined with MOMENTARY it could be used for sample accurate > >> tempo tapping. > >> > > > >Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? > >You'd have a buffer-full of samples and apply frequency shift to them, which w > >ould change the length of that buffer, which you couldn't give to JACK unless > >you do some rebuffering. > > this is true of *any* output paradigm. the audio interface only > accepts N frames per second. if you had N frames to deliver in one > second, then stretched them to N*2 frames, it will necessarily take > you twice as long to deliver them - the interface isn't going to speed > up for you. Yes, but then, if you are also having input from realtime-type interface the buffer must be of fixed size. > >Correct me if I'm wrong. We have similar issue with ecasound's Pitch Shifter > >operator in connection with JACK. > > steve has written LADSPA pitch shifters and they work just fine with > the fixed-sized buffer paradigm. Yep, I was just intrigued with the tempo tapping, which cannot be achieved when in and out are realtime. (like jack-rack) Or then I maybe misunderstood the term. janne
Re: [linux-audio-dev] Additional LADSPA hints
On Thu, Jan 16, 2003 at 05:31:56PM +0200, janne halttunen wrote: > > No, I dont think so. An audio rate control is just one that has a value > > per sample, instead of a value per block. Its usful for things like FM > > frequency which can be changed very quickly. Hey, I just thought of a use > > for it ;) > > But how can it be used for "tempo tapping" then? Tempo tapping is a way of determining the tempo of the musicians music, you tap the button in time to the music and the software then uses that to sync delays and similar effects. It doesn't do any time stetching. - Steve
Re: [linux-audio-dev] Additional LADSPA hints
Steve Harris <[EMAIL PROTECTED]> writes: > > On Wed, 15 Jan 2003 18:13:35 + > > Steve Harris <[EMAIL PROTECTED]> wrote: > > > > > AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled > > > by a high time res. slider or control data, but shouldn't be connected to > > > the next audio signal by default. I can't think of any simple examples off > > > hand, but combined with MOMENTARY it could be used for sample accurate > > > tempo tapping. > > > > > > My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL > > > could be useful, but might be painful for hosts to implement. I dont have > > > any particular use for it right now. > On Thu, Jan 16, 2003 at 02:38:53PM +0200, janne halttunen wrote: > > Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? > > You'd have a buffer-full of samples and apply frequency shift to them, > > which would change the length of that buffer, which you couldn't give to > > JACK unless you do some rebuffering. > > No, I dont think so. An audio rate control is just one that has a value > per sample, instead of a value per block. Its usful for things like FM > frequency which can be changed very quickly. Hey, I just thought of a use > for it ;) There's a syntactic ambiguity in the name AUDIO_RATE_CONTROL. Steve uses it to describe a Controller which runs at Audio Rate (i.e. sample clock speed). But, Janne understood it to mean a Controller *of* the Audio Rate, which is not allowed. Maybe a different name (CONTINUOUS_CONTROLLER?) would be clearer. Regards, -- Jack O'Quin Austin, Texas, USA
Re: [linux-audio-dev] Additional LADSPA hints
>On Wed, 15 Jan 2003 18:13:35 + >Steve Harris <[EMAIL PROTECTED]> wrote: > >> AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled >> by a high time res. slider or control data, but shouldn't be connected to >> the next audio signal by default. I can't think of any simple examples off >> hand, but combined with MOMENTARY it could be used for sample accurate >> tempo tapping. >> >> My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL >> could be useful, but might be painful for hosts to implement. I dont have >> any particular use for it right now. > >Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? >You'd have a buffer-full of samples and apply frequency shift to them, which w >ould change the length of that buffer, which you couldn't give to JACK unless >you do some rebuffering. this is true of *any* output paradigm. the audio interface only accepts N frames per second. if you had N frames to deliver in one second, then stretched them to N*2 frames, it will necessarily take you twice as long to deliver them - the interface isn't going to speed up for you. >Correct me if I'm wrong. We have similar issue with ecasound's Pitch Shifter >operator in connection with JACK. steve has written LADSPA pitch shifters and they work just fine with the fixed-sized buffer paradigm. --p
Re: [linux-audio-dev] Additional LADSPA hints
On Thu, 16 Jan 2003 13:58:58 + Steve Harris <[EMAIL PROTECTED]> wrote: > On Thu, Jan 16, 2003 at 02:38:53PM +0200, janne halttunen wrote: > > On Wed, 15 Jan 2003 18:13:35 + > > Steve Harris <[EMAIL PROTECTED]> wrote: > > > > > AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled > > > by a high time res. slider or control data, but shouldn't be connected to > > > the next audio signal by default. I can't think of any simple examples off > > > hand, but combined with MOMENTARY it could be used for sample accurate > > > tempo tapping. > > > > Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? > > No, I dont think so. An audio rate control is just one that has a value > per sample, instead of a value per block. Its usful for things like FM > frequency which can be changed very quickly. Hey, I just thought of a use > for it ;) But how can it be used for "tempo tapping" then? janne
Re: [linux-audio-dev] Additional LADSPA hints
On Thu, Jan 16, 2003 at 02:38:53PM +0200, janne halttunen wrote: > On Wed, 15 Jan 2003 18:13:35 + > Steve Harris <[EMAIL PROTECTED]> wrote: > > > AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled > > by a high time res. slider or control data, but shouldn't be connected to > > the next audio signal by default. I can't think of any simple examples off > > hand, but combined with MOMENTARY it could be used for sample accurate > > tempo tapping. > > > > My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL > > could be useful, but might be painful for hosts to implement. I dont have > > any particular use for it right now. > > Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? > You'd have a buffer-full of samples and apply frequency shift to them, > which would change the length of that buffer, which you couldn't give to > JACK unless you do some rebuffering. No, I dont think so. An audio rate control is just one that has a value per sample, instead of a value per block. Its usful for things like FM frequency which can be changed very quickly. Hey, I just thought of a use for it ;) - Steve
Re: [linux-audio-dev] Additional LADSPA hints
On Wed, 15 Jan 2003 18:13:35 + Steve Harris <[EMAIL PROTECTED]> wrote: > AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled > by a high time res. slider or control data, but shouldn't be connected to > the next audio signal by default. I can't think of any simple examples off > hand, but combined with MOMENTARY it could be used for sample accurate > tempo tapping. > > My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL > could be useful, but might be painful for hosts to implement. I dont have > any particular use for it right now. Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? You'd have a buffer-full of samples and apply frequency shift to them, which would change the length of that buffer, which you couldn't give to JACK unless you do some rebuffering. Correct me if I'm wrong. We have similar issue with ecasound's Pitch Shifter operator in connection with JACK. janne
Re: [linux-audio-dev] Additional LADSPA hints
On Wed, Jan 15, 2003 at 07:48:48 +0100, David Olofson wrote: > > AUDIO_RATE_CONTROL. Hints than an audio control should/could be > > controlled by a high time res. slider or control data, but > > shouldn't be connected to the next audio signal by default. I can't > > think of any simple examples off hand, but combined with MOMENTARY > > it could be used for sample accurate tempo tapping. ... > Considering the sidechain deal, this *idea* seems useful - but > sidechains are *not* control ports, so this would still be the wrong > tool for that job, the way I understand it. Some other hint would > have to be used for that, and preferably one that's less specific > than "SIDECHAIN". That sounds useful, but its a seperate issue. I cant think of a way of generalising it... maybe OPTIONAL? i.e. this plugin will still do something useful if this port isn't connected. > > RANDOMISABLE. Hints that its useful/meaningful to randomise the > > port if the user hits a button. This is useful for the steps of > > control sequencers, reverbs, and just about anything that's > > complex. Allows you to specify which controls can be randomised > > without anything too supprising happening to the user (eg. sudden > > +100dB gain would be unpleasent). > > That sound cool, although I'm not a great fan of random control data > myself. > > > I'd rather record the "random" data, so I can edit it if needed, and > be sure that it'll always sound the same every time I play the song. > I get nervous otherwise! ;-) And I've had some bad experiences with > noise generators and resonant filters... In Audiality, I decided to > reset the NG before rendering each waveform, to guarantee that a > certain script always generates the exact same waveform. > What was suggested is that the host would provide a control and /if/ the user clicked it it would randomise all the hinted control once. Its just for when you run out of inspiration or are feeling brave ;) If you were using host automation at the time I would expect it to record the changes and play them back. Its not like a random input that varies every block. FWIW I agree with you on random data streams, they should be repeatable. My "delayorama" plugin (well, not really mine, the idea was nicked from Waves via Paul D. IIRC) has a random bias, but its seeded from a user controlled value, so the the "random" bias will always be the same. - Steve
Re: [linux-audio-dev] Additional LADSPA hints
On Wednesday 15 January 2003 19.13, Steve Harris wrote: > There have been a few suggestions recently, I'l try to summarise > them for comment. > > MOMENTARY. A hint to suggest that a control should behave like a > momentary switch, eg. on for as long as the user holds down the > key/mouse button/whatever. Useful for reset or sync controls for > example. Would be useful in the DJ flanger. Only applies to TOGGLED > controls. This sounds like a nice, clean and useful feature. > AUDIO_RATE_CONTROL. Hints than an audio control should/could be > controlled by a high time res. slider or control data, but > shouldn't be connected to the next audio signal by default. I can't > think of any simple examples off hand, but combined with MOMENTARY > it could be used for sample accurate tempo tapping. I'm not sure... What does it *really* mean? Sure, "this is an audio rate control" - but that only suggests to hosts that it *might* be a bad idea to assume that it should be connected to an audio port... Considering the sidechain deal, this *idea* seems useful - but sidechains are *not* control ports, so this would still be the wrong tool for that job, the way I understand it. Some other hint would have to be used for that, and preferably one that's less specific than "SIDECHAIN". > RANDOMISABLE. Hints that its useful/meaningful to randomise the > port if the user hits a button. This is useful for the steps of > control sequencers, reverbs, and just about anything that's > complex. Allows you to specify which controls can be randomised > without anything too supprising happening to the user (eg. sudden > +100dB gain would be unpleasent). That sound cool, although I'm not a great fan of random control data myself. I'd rather record the "random" data, so I can edit it if needed, and be sure that it'll always sound the same every time I play the song. I get nervous otherwise! ;-) And I've had some bad experiences with noise generators and resonant filters... In Audiality, I decided to reset the NG before rendering each waveform, to guarantee that a certain script always generates the exact same waveform. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! . | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---
[linux-audio-dev] Additional LADSPA hints
There have been a few suggestions recently, I'l try to summarise them for comment. MOMENTARY. A hint to suggest that a control should behave like a momentary switch, eg. on for as long as the user holds down the key/mouse button/whatever. Useful for reset or sync controls for example. Would be useful in the DJ flanger. Only applies to TOGGLED controls. AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled by a high time res. slider or control data, but shouldn't be connected to the next audio signal by default. I can't think of any simple examples off hand, but combined with MOMENTARY it could be used for sample accurate tempo tapping. RANDOMISABLE. Hints that its useful/meaningful to randomise the port if the user hits a button. This is useful for the steps of control sequencers, reverbs, and just about anything that's complex. Allows you to specify which controls can be randomised without anything too supprising happening to the user (eg. sudden +100dB gain would be unpleasent). -- My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL could be useful, but might be painful for hosts to implement. I dont have any particular use for it right now. - Steve
